Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Einführung ORM & JPA Persistente Domänenmodelle mit JPA 2.0 und Bean Validation."—  Präsentation transkript:

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

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

3 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)

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

5 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

6 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

7 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

8 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

9 DBOO 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

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

11 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

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

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

14 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

15 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

16 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

17 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

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

19 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

20 Problematische Abfrage: Alle Tupel bestehend aus Vorname, Nachname und Produktname FirstNameLastNameProductName ThomasAndersonBeretta 92FS 9mm ThomasAndersonBlack Coat ThomasAndersonCool Sunglasses TylerDurdenPerfumed Soap Relationale Suche / Reports

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

22 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: 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: EclipseLink ist die Referenzimplementation Die bekannten JPA Providers unterstützen alle JPA2

23 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

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

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


Herunterladen ppt "Einführung ORM & JPA Persistente Domänenmodelle mit JPA 2.0 und Bean Validation."

Ähnliche Präsentationen


Google-Anzeigen