Einführung
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, proposed final draft: 29.3.2009 EclipseLink ist die Referenzimplementation Alle JPA Providers arbeiten zur Zeit an der Implementation von JPA 2
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