Objektrelationales Mapping mit JPA

Einführung

Jonas BandiSimon Martinelli

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...

Ausgangslage: Domain ModelAnwendung 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

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: Relational Datenbanken

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

• OO-Technologie für die Applikationsentwicklung

• 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

Ausgangslage: Der Konflikt

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

Der O/R-MismatchDB 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

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-MappingFolgende 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!

Relationale Suche / Reports • 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

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 werden

• Alle beteiligten Objekte müssen geladen werden (Performance!)

JPA – Java Persistence APIJPA ist eine Bestrebung OR-Mapping mit Java zu standardisieren.JPA ist ein Teil der EJB 3 Spezifikation welche vom JCP erarbeitet

wurdeJSR 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, proposed final draft: 29.3.2009

EclipseLink ist die Referenzimplementation

Alle JPA Providers arbeiten zur Zeit an der Implementation von JPA 2

Technologiestack

Session Beans / Java Applikation

Java Persistence API

Java Persistence API Implementation

JDBC - Driver

JDBC API

EJB 3.0 Spezifikation

JDBC 4.0

RDB

SQL SQL 2003 oder Dialekte

Java 5+

Herstellerspezifisch

TopLink, Hibernate, OpenJPA etc.

Java API

Packagesjavax.persistencejavax.persistence.spi

ClassesPersistence

InterfacesEntityManagerFactoryEntityManagerEntityTransactionQuery

Runtime Exceptions ( ~8 )RollbackException

Annotations ( ~64 )EntityIdOneToOneOneToMany

Enumerations ( ~10 )InheritanceTypeCascadeTypeFetchType

JPA Providers

• Die bekanntesten JPA Providers sind:– Hibernate

– Toplink / TopLink Essentials / EclipseLink

– KODO / OpenJPA

– JPOX / DataNucleus

• Weniger bekannt sind:

– Apache Cayenne

– Resin Amber

– CocoBase