Persistente Domänenmodelle mit JPA 2.0 und Bean Validation Einführung ORM & JPA Persistente Domänenmodelle mit JPA 2.0 und Bean Validation 1

Silver Bullet oder unnötiger Overhead? Objektrelationales Mapping ist ein umstrittenes Thema, das immer wieder Anlass für hitzige Diskussionen bietet. Hier zwei Beispiele... 2

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 3

The Vietnam of Computer Science Ted Neward: “Object/Relational Mapping is the Vietnam of Computer Science” (Juni 2006). Original Blog Post: http://tinyurl.com/heapf PDF: 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... 4

Ausgangslage Domain Model 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 5

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 6

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 7

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 OO erlaubt die Konstruktion von neuen Typen (Klassen). DB: nur Strukturierung von primitiven Datentypen in Tupel und Sets Referenzen sind ein explizites Konstrukt in OO-Sprachen FKs sind kein explizites Konstrukt (Duplizierung von Schlüsselwerten) Referenzen sind gerichtet. Navigation entlang von Referenzen ist ein wichtiges Konzept. FKs sind nicht gerichtet. Man kann nicht entlang von FKs navigieren. Identität: In OO-Sprachen ist das Konzept der Identität tief verankert (this) Das Relationale Model kommt auch ohne Identität aus 8

Der O/R-Mismatch 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 Daten leben länger als Applikationen DB: Transformation / Migration / Reports über lange Zeit DB: SQL untypisierte Sicht auf die Daten OO: Streng typisierte Sicht auf die Daten 9

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

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 EJB2: 2001 JDO (JSR 12): 2002 JDO2 (JSR 243): 2006, JDO 2.2 2008, JDO 2.3 in planning JPA (JSR 220): 2006 JPA 2 (JSR 317): 2009 11

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

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

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 14

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 15

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 16

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 17

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

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 19

Relationale Suche / Reports Problematische Abfrage: Alle Tupel bestehend aus Vorname, Nachname und Produktname FirstName LastName ProductName Thomas Anderson Beretta 92FS 9mm Black Coat Cool Sunglasses Tyler Durden Perfumed Soap 20

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!) 21

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 22

Technologiestack Session Beans / Java Applikation Java 5+ Java Persistence API JPA Spezifikation Java Persistence API Implementation EclipseLink (TopLink), Hibernate, OpenJPA etc. JDBC API JDBC 4.0 JDBC - Driver Herstellerspezifisch SQL SQL 2003 oder Dialekte RDB 23

Java API Runtime Exceptions ( ~8 ) RollbackException Annotations ( ~64 ) Entity Id OneToOne OneToMany Enumerations ( ~10 ) InheritanceType CascadeType FetchType Packages javax.persistence javax.persistence.spi Classes Persistence Interfaces EntityManagerFactory EntityManager EntityTransaction Query 24

JPA Providers Die bekanntesten JPA Providers sind: Hibernate Toplink / TopLink Essentials / EclipseLink KODO / OpenJPA JPOX / DataNucleus Weniger bekannt sind: Apache Cayenne Resin Amber CocoBase 25