Einführung ORM & JPA

Persistente Domänenmodelle mit JPA 2.0 und Bean Validation

Silver Bullet oder unnötiger Overhead?

Objektrelationales Mapping ist ein umstrittenes Thema, das immer wieder Anlass für hitzige Diskussionen bietet.

Hier zwei Beispiele...

Flame Wars

“The Best ORM is No ORM” “The database is an object.” “ORM is, for the most part,

solving the wrong problem. In fact the problem does not really exist.”

From The ServerSide: Which .NET ORM is best? (November 2004)http://tinyurl.com/377lua

The Vietnam of Computer Science

Ted Neward: “Object/Relational Mapping is the Vietnam of Computer Science” (Juni 2006).Original Blog Post: http://tinyurl.com/heapfPDF: http://www.odbms.org/about_news_20070212.html

“Law of Diminishing Returns” Schnelle anfängliche Erfolge führen zu grossen

Erwartungen Mit dem Fortschreiten des Unterfangens

werden die Erfolge aber immer spärlicher und die dafür notwendigen Investitionen immer grösser

Schlussendlich werden die Investitionen nicht mehr durch den Gewinn gerechtfertigt. Aber es gibt keinen Weg zurück...

Anwendung von bewährten OO-Techniken für die Implementation der Geschäftslogik:Kapselung, Vererbung, Polymorphie, Design Patterns ...

OO verspricht:• bessere Skalierung bei zunehmender Komplexität

• bessere Erweiterbarkeit• bessere Wartbarkeit• weniger Redundanz

Ausgangslage Domain Model

Ausgangslage: Relationale Datenbanken

Vorherrschende Technologie zum Speichern von Daten im Enterprise-Umfeld.

Gründe: Grosse Investitionen Bewährte, ausgereifte Technologie Flexibilität, Applikationsunabhängigkeit Daten leben länger als Applikationen Optimierte Konzepte zum Speichern

von Daten

Ausgangslage: Der Konflikt

De facto Standard-Konstellation für Enterprise-Applikationen:

OO-Technologie für die Applikations-entwicklung

Relationale Datenbanken für die Persistenz der Daten

An dieser Ausgangslage wird sich mittelfristig kaum etwas ändern.

Der OO-Ansatz und der relationale Ansatz weisen grundsätzliche Unterschiede auf

Aus diesen Unterschieden resultiert der sog. Object-Relational-Mismatch

Der O/R-Mismatch

Technische Ausprägungen des O/R-Mismatch: Typen-Systeme

Null Datum/Zeit

Abbildung von Beziehungen Richtung Mehrfachbeziehungen

Vererbung Identität

Objekte haben eine implizite Identität Relationen haben eine explizite Identität (Primary Key)

Transaktionen

DB OO

Designziele • Speichern und Abfragen von Daten

• Speicherung unabhängig von konkreten Business-Problemen

• Vereinigung von Zustand und Verhalten

• Kapselung, Modularisierung, Abstraktion

• Modellierung konkreter Business-Probleme

Architektur-ansätze

• Client/Server: verteiltes System

• Objekte sind lokal und nicht verteilt

Abfrage/Zugriff

• Deklarative Abfragesprache

• Beziehungen zwischen Daten müssen nicht explizit definiert sein

• Imperative Navigation entlang von Referenzen

• Beziehungen zwischen Objekten müssen explizit definiert sein

Der O/R-Mismatch

Der O/R-Mismatch

In heutigen Enterprise Umfeldern ist der O/R-Mismatch ein Fakt.

Der O/R-Mismatch folgt aus konzeptionellen Unterschieden der zugrundeliegenden Technologien.

Es gibt viele verschiedene Möglichkeiten den O/R-Mismatch zu überwinden.

O/R-Mapping resp. O/R-Mapping Frameworks sind ein möglicher Lösungsansatz.

History

Konzepte zum Überbrücken des O/R-Mismatch existieren seit es OO gibt. Unterschiedliche Ansätze wie der O/R-Mismatch

überwunden werden soll

Bekannteste Java Frameworks Hibernate TopLink, TopLink Essentials, EclipseLink KODO, OpenJPA JPOX , DataNucleus

Java Standardisierung: EJB2, JDO, JPA

Versprechen von O/R-Mapping

Die Applikation wird von der DB entkoppelt Applikationsentwickler muss kein SQL beherrschen Das relationale Modell der Datenbank hat keinen Einfluss auf

das OO-Design

Automatische Persistenz Automatisierte Abbildung der Objekte in die relationalen

Strukturen Der Applikationsentwickler muss sich nicht um die “low-level”-

Details des CLI (z.B. connections) kümmern.

Transparente Persistenz / Persistence Ignorance Die Klassen des Domain-Models wissen nicht dass sie

persistiert und geladen werden können und haben keine Abhängigkeit zur Persistenz-Infrastruktur.

Versprechen von O/R-Mapping

Abstraktion Abstraktion ist eines der wichtigsten Werkzeuge

um Komplexität zu bewältigen

Separation of Concerns Bei der Applikationsentwicklung kann man sich

ausschliesslich auf die Geschäftsprobleme konzentrieren

Infrastruktur-Probleme können separat gelöst werden und beeinflussen das Design und die Implementation der Geschäftslogik nicht.

Versprechen von O/R-Mapping Frameworks

Umsetzung der Versprechen von O/R-Mapping Einsatz von bewährten Patterns und Konzepten Einsparungen von viel Code

Manuell codierter DataAccess-Layer kann einen grossen Code-Anteil ausmachen

Referenzbeispiele zeigen Einsparungen um Faktor 7

Strukturierung / Layerung des Codes vorgegeben

Pitfalls von O/R-Mapping Frameworks

O/R-Mapping-Frameworks sind komplex und bieten viel Funktionalität. Hibernate Core: 765k LOC, 206 Personen-Jahre, $11 Mio (Source:

Ohloh.net)

O/R-Mapping-Frameworks sind keine Rapid-Application-Development-Tools

Der Einsatz eines O/R-Mapping-Frameworks hat Einfluss auf die Architektur und den Design der gesamten Applikation

Die zugrundeliegenden Konzepte sollten verstanden sein. Gründliche Auseinandersetzung ist Voraussetzung für den

erfolgreichen Einsatz eines O/R-Mapping-Frameworks

Konzeptionelle Probleme beim O/R-Mapping

Folgende konzeptionelle Probleme sollten beim O/R-Mapping beachtet werden:

Location Transparency Optimiertes SQL Mengen-Manipulationen Relationale Suche / Reports /

OLAP

Location Transparencey

Alle Daten immer verfügbar Für die Applikation sollte es keinen

Unterschied machen, ob die sich Daten im lokalen Speicher oder auf der entfernten Datenbank befinden.

Wieviele Daten werden geladen? Zuviele: Speicher, Bandbreite -> Ladezeit! Zuwenige: Konstantes Nachladen -> Ladezeit! Stichworte: Lazy-Loading / Eager-Loading

Dynamisch Generiertes SQL

SQL ist nicht so performant wie handgeschriebens, getuntes SQL Assembler anybody? Dynamisch generiertes SQL muss auch nicht

gewartet werden! Ausgereifte Frameworks generieren gut

optimiertes SQL (torpedo-group.org)

Performance Stored Procedures sind nicht performanter als

dynamisches SQL!

Nutzung von relationalen Konzepten, die keine Entsprechung in der OO-Welt haben Unproblematische

Abfragen:

– Alle Personen, welche einen schwarzen Mantel bestellen.

– Alle Personen, welche einen schwarzen Mantel bestellen mit all ihren Bestellungen und allen Bestell-Posten

Relationale Suche / Reports

Problematische Abfrage: Alle Tupel bestehend aus Vorname, Nachname

und Produktname

FirstName LastName ProductName

Thomas Anderson Beretta 92FS 9mm

Thomas Anderson Black Coat

Thomas Anderson Cool Sunglasses

Tyler Durden Perfumed Soap

Relationale Suche / Reports

Relationale Suche / Reports

Probleme:Karthesisches Produkt

In der DB sehr effizient umgesetzt In der OO-Welt keine Entsprechung

Die Struktur des Resultats der Anfrage existiert nicht in der OO-Welt Es gibt keinen Typ mit den Attributen (Vorname, Nachname, Produktname) Die relationale Welt erlaubt flexible (untypisierte) Sichten auf die Daten

(Deklarative ad-hoc formulierte Anfragen) Resultat einer Anfrage kann völlig entkoppelt sein von der Struktur wie die

Daten gespeichert werden. Die OO-Welt verlangt definierte, stark typisierte Strukturen

Das ‚Flachdrücken‘ / ‚Denormalisieren‘ muss in der OO-Welt manuell ausgeführt werdenAlle beteiligten Objekte müssen geladen werden (Performance!)

JPA – Java Persistence API JPA ist eine Bestrebung OR-Mapping mit Java zu

standardisieren JPA ist ein Teil der EJB 3 Spezifikation welche vom JCP

erarbeitet wurde JSR 220, final release: 2.5.2006 TopLink Essentials ist die Referenzimplementation

Es gibt verschiedene JPA Implementationen, diese werden auch JPA Providers genannt

JPA 2 ist eine eigenständge Spezifikation, welche auf JPA aufbaut und etliche zusätzliche Features bietet JSR 317, final release: 10.12.2009 EclipseLink ist die Referenzimplementation Die bekannten JPA Providers unterstützen alle JPA2

Session Beans / Java Applikation

Java Persistence API

Java Persistence API Implementation

JDBC - Driver

JDBC API

JPA Spezifikation

JDBC 4.0

RDB

SQL SQL 2003 oder Dialekte

Java 5+

Herstellerspezifisch

EclipseLink (TopLink), Hibernate, OpenJPA etc.

Technologiestack

Packagesjavax.persistencejavax.persistence.spi

ClassesPersistence

InterfacesEntityManagerFactoryEntityManagerEntityTransactionQuery

Runtime Exceptions ( ~8 )RollbackException

Annotations ( ~64 )EntityIdOneToOneOneToMany

Enumerations ( ~10 )InheritanceTypeCascadeTypeFetchType

Java API

JPA Providers

Die bekanntesten JPA Providers sind: Hibernate Toplink / TopLink Essentials / EclipseLink KODO / OpenJPA JPOX / DataNucleus

Weniger bekannt sind: Apache Cayenne Resin Amber CocoBase