Literatur. 3. Java Persistence API ( JPA)

Transkript

1 3. Java Persistence API ( JPA) Problem: OO in relationale DB Idee des Persistence Mapper Einfache Entity-Klasse Lebenslauf eines Entity-Objekts Umsetzung von 1:N- und M:N-Relationen Konsistenzüberwachung Vererbung Anfragen Literatur Sun Microsystems, JSR 220: Enterprise JavaBeans, Version 3.0, Java PersistenceAPI (ejb-3_0-fr-spec-persistence.pdf, ist der Standard; trotzdem sehr gut lesbar!) Auch für Teile der weiteren Vorlesung C. Bauer, G. King, Java PersistencewithHibernate, Manning, Greenwich (USA) 2007 M. Keith, M. Schincariol, Pro EJB 3 -Java PersistenceAPI, Apress, Berkeley (USA), Klassische Wege zur Verbindung SW und DB Nutzung relationaler DB in OO-Programmen DB werden meist nicht alleine entwickelt, sie müssen mit umgebender SW integriert werden. Es gibt verschiedene Ansätze, die gerade bei der Anbindung von OO-SW relevant sind: - SW wird (z.b: mit PL/SQL) in der Datenbank entwickelt (hierzu gibt es auch objektorientierte Ansätze), externe SW kann auf Prozeduren und Funktionen zugreifen. - SQL-Aufrufe werden direkt in die SW eingebettet (EmbeddedSQL) bzw. Aufrufe werden durch ein einfaches Framework (z.b. JDBC, SQLJ) gekapselt. (Frage: wie bekomme ich Objekte in die DB?) - DB-Entwicklung und SW-Entwicklung wird eng miteinander verzahnt, hierzu stehen ausgereifte Development- Frameworks zur Verfügung (EJB,.NET) Bisheriger Ansatz: relationale DB vorhanden, wird an OO-Programm angeschlossen. Was ist, wenn DB zusammen mit OO- Programm entwickelt wird? erster Ansatz: warum nicht genau so vorgehen Oberfläche + Geschäftslogik DB-Zugriffsschicht z.b. JDBC relationale Datenbank 76 77

2 Lagerverwaltung ( ein kleines OO- Modell) Aufgabe und Ansatz Lagerraum -nummer : String +verkaufswertberechnen() : float 1 - artikel bezeichnet eine Collection von en in einem Lagerraum - mit verkaufspreis() wird die Mehrwertsteuer eingerechnet, die bei Büchern anders sein soll. beinhaltet -artikel * -name : String -lagermenge : int -preis : float +() : +verfuegbareanzahl() : int +verkauft(anzahl : int) : void +einlagern(anzahl : int) : void +verkaufspreis() : float Objekte der im Lagerhaltungsmodell vorgestellten Klassen sollen persistentin einer relationalen DB abgespeichert werden Bei der Anbindung an die Datenbank sollen möglichst viele OO-Errungenschaften (Kapselung, Vererbung, Polymorphismus) übernommen werden Grundidee: Das Klassendiagramm kann ohne Methoden als ER-Diagramm gelesen werden, es beinhaltet eine 1:N und zwei 1:C Beziehungen. Lebensmittel -verfallsdatum : Date +verlustam(stichtag : Date) : float Buch +verkaufspreis() : float Anmerkung: Dieser Übersetzungsansatz war ein beliebtes Tummelfeld von Programmierern, es wird nur ein möglicher Ansatz vorgestellt Umgang mit Kapselung Objekte der Klasse können leicht in folgende Tabelle übersetzt werden. OID name lagermenge preis -name : String -lagermenge : int -preis : float +() : +verfuegbareanzahl() : int +verkauft(anzahl : int) : void +einlagern(anzahl : int) : void +verkaufspreis() : float Anmerkungen Typischerweise werden Klassenvariablen nicht mit den jeweiligen Objekten abgespeichert, sie müssen explizit behandelt werden Es stellt sich generell die Frage, welche zusätzlichen Informationen in welchen Tabellen verwaltet werden sollen zusätzlicher PrimaryKey vergeben, falls namenicht eindeutig Kapselungsidee wird aufgegeben, da man über die Datenbank immer direkt auf die Attribute zugreifen kann, nur durch Mehraufwand einschränkbar: Lösung auf der Zugriffsebene im OO-Programm (umgehbar) Spezielle Nutzer und Rechte, Nutzung von Views(Aufwand) 80 81

3 Umgang mit Vererbung Vererbung kann durch eine zusätzliche Tabelle mit einer Referenz implementiert werden, dabei ist OID Schlüssel und Fremdschlüssel aus Lebensmittel OID verfallsdatum Lebensmittel -verfallsdatum : Date +verlustam(stichtag : Date) : float Für jede Vererbungsebene wird eine neue Tabelle benötigt, was den Zugriff aufwändig macht Durch die vorgeschlagene Struktur wird die Sichtweise ein Lebensmittel ist ein unterstützt Umgang mit Polymorphismus Wie funktioniert Polymorphismus? public float verkaufswertberechnen(){ float ergebnis=0.0f; for( tmp:artikel) ergebnis= ergebnis+ tmp.verfuegbareanzahl()*tmp.verkaufspreis(); return ergebnis; In der bisherigen relationalen Übersetzung muss sichergestellt werden, dass das richtige Objekt geladen wird Die genaue Klassendefinition bekommt man im vorgestellten Ansatz nur, wenn man alle zu Unterklassen gehörigen Tabellen untersucht, ob die OID vorkommt Alternativ kann man sich die genaue Klassenzugehörigkeit in einem weiteren Attribut der Tabelle merken Umgang mit Objektidentität Objektidentität in der Datenbank wird durch den Primary Key garantiert Wird das Objekt aus der Datenbank gelesen, ist der Nutzer verantwortlich, dass kein zweites Exemplar des gleichen Objekts geladen wird Alternative: Beim ersten Herauslesen wird ein Flag (ein zusätzliches Attribut) gesetzt, dass sich das Exemplar außerhalb der DB befindet (Ansatz fordert viel Programmierdisziplin, insbesondere bei der Programmterminierung) Umgang mit Beziehungen zwischen Objekten Exemplarvariablen, die Collectionsoder andere nicht triviale Objekttypen enthalten, müssen explizit durch eine oder mehrere Relationen oder Erweiterungen von Tabellen modelliert werden (der Ansatz ist vom Übergang vom ER-Diagramm zur Tabellenstruktur bekannt) Lagerraum OID name 1 lagermenge beinhaltet preis -artikel * lagerraum_oid Frage: Warum passt die skizzierte Lösung eigentlich nicht zum UML-Diagramm? 84 85

4 Bearbeiten von Objekten Wir haben gesehen, dass einfache Objekte häufig über mehrere Tabellen verteilt werden, d.h. zum Einlesen und Bearbeiten sind relativ aufwändige SQL-JOINS notwendig Weiterhin muss das OO-Programm die eindeutige Referenz eines Objektes in der relationalen DB kennen Beispiel: Einlesen eines Lebensmittels, das an eine Variable mit Namen banane gebunden war SELECT name, lagermenge, preis, verfallsdatum FROM Identifikation, Lebensmittel, WHERE Identifikation.Name = 'banane' AND Identifikation.OID =.OID AND.OID = Lebensmittel.OID Zwischenfazit Selbst bei Beispielen, in denen der Einsatz relationaler Datenbanken sinnvoller Standard ist (Lagerverwaltung), wird die Verknüpfung eines OO-Programms mit relationaler Datenhaltung aufwändig Die Nutzung relationaler Datenbanken in OO-Programmen sollte immer über eine DB-Kapselung, die den Zugriff auf die DB regelt, erfolgen Für den Kapselungsansatz stehen verschiedene e zur Verfügung (z. B. Hibernate, TopLink), JPA spezifiziert gemeinsames Interface Verwandte Ansätze: direkte Nutzung einer OO-Datenbank, Programmierung mit JDO Konzept von Persistence-Mappern Persistence-Mapper(PM) muss wissen, welche Objekte persistiertwerden sollen -> markiere Klassen, deren Objekte verwaltet werden sollen Persistence-Mappermuss Beziehungen zwischen Objekten kennen Ablauf: Nutzer benutzt Objekt unter Verwaltung; dann übernimmt PM die Überwachung, führt Änderungen aus, regelt den Zugriff mehrerer Nutzer Ablauf: Nutzer erzeugt Objekt und muss PM einmal mitteilen, dieses zu verwalten PM kann selbst regeln, wie Aufgaben realisiert werden (Tabellenstruktur, Transaktionssteuerung) Beispiel ( 1 / 6 ) package jpabeispiel1; import javax.persistence.entity; import public class Mitarbeiter private int minr; private String name; public Mitarbeiter(){ //leerer Konstruktor benötigt public Mitarbeiter(int minr, String name) { //erlaubt this.minr = minr; this.name = name; public int getminr() {return minr; public void setminr(int minr) {this.minr = minr; public String getname() {return name; public void setname(string name) {this.name = name; 88 89

5 Beispiel ( 2 / 6 ) Persistence.xml liegt im Ordner META-INF (projektartabhängig) Detaileinstellungen von JPA-Realisierungabhängig (z. B. Hibernate, TopLink) <?xml version="1.0" encoding="utf-8"?> <persistence version="1.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" <persistence-unit name="jpabeispiel1pu" transaction-type="resource_local"> <provider>org.hibernate.ejb.hibernatepersistence</provider> <class>jpabeispiel1.mitarbeiter</class> Beispiel ( 3 / 6 ) <properties> <property name="hibernate.connection.username" value="kleuker"/> <property name="hibernate.connection.driver_class" value="org.apache.derby.jdbc.clientdriver"/> <property name="hibernate.connection.password" value="kleuker"/> <property name="hibernate.connection.url" value="jdbc:derby://localhost:1527/projver"/> <property name="hibernate.cache.provider_class" value="org.hibernate.cache.nocacheprovider"/> <property name="hibernate.hbm2ddl.auto" value="update"/> </properties> </persistence-unit> </persistence> Beispiel ( 4 / 6 ) package jpabeispiel1; import java.util.list; import javax.persistence.entitymanager; import javax.persistence.entitymanagerfactory; import javax.persistence.persistence; public class Main { private EntityManagerFactory emf = Persistence. createentitymanagerfactory("jpabeispiel1pu"); private EntityManager em = emf.createentitymanager(); public void beispieldaten() { String namen[] = {"Egon", "Erwin", "Ute", "Aische"; em.gettransaction().begin(); for (int i=0; i<namen.length; i++) em.persist(new Mitarbeiter(i,namen[i])); Beispiel ( 5 / 6 ) public void datenzeigen() { for (Mitarbeiter m : (List<Mitarbeiter>) em.createquery("select m FROM Mitarbeiter m"). getresultlist()) { System.out.println(m.getMinr() + ": " + m.getname()); public static void main(string[] args) { Main m = new Main(); m.beispieldaten(); m.datenzeigen(); m.beenden(); // mit em.close() 0: Egon 1: Erwin 2: Ute 3: Aische 92 93

6 Beispiel ( 6 / 6 ) Falls noch keine Tabelle Mitarbeiter existiert, wird diese angelegt 94 Suchen und Bearbeiten von einzelnen Objekten public void namenaendern(){ int eingabe=-1; while(eingabe!=0){ System.out.print("Welche Nummer (Ende mit 0): "); eingabe=new Scanner(System.in).nextInt(); Mitarbeiter m = em.find(mitarbeiter.class, eingabe); if(m == null) System.out.println("Witzbold"); else{ System.out.print("Neuer Name (alt:"+m.getname()+"): "); String name=new Scanner(System.in).next(); EntityTransaction tr = em.gettransaction(); tr.begin(); m.setname(name); tr.commit(); 95 Entity ist POJO Primary Key Entity-Klassen-Objekte sind klassische Plain Old Java Objects Verpflichtung: public(oder protected) Default-Konstruktor Exemplarvariablen private oder protected, Zugriff über get... und set... Klasse, Methoden, Exemplarvariablen nicht final Serialisierbar[zumindest sehr sinnvoll] keine weiteren Einschränkungen beliebige weitere Methoden Vererbung (auch Entity von Nicht-Entity[aufwändig]) Nutzung abstrakte Klassen Typisch: Primary Key = GenerationType.AUTO) private int minr; folgende Datentypen erlaubt primitive Java-Typen (int, long, ) Wrapper von primitiven Java-Typen (Integer, Long, ) java.lang.string java.util.date java.sql.date 96 97

7 Persistierbare Typen/ Klassen Primitive Typen (byte, char, int, long, float, double, boolean) java.lang.string Andere serialisierbare Typen: Wrapper der primitiven Typen java.math.biginteger java.math.bigdecimal java.util.date, java.util.calendar java.sql.date, java.sql.time, java.sql.timestamp Nutzerdefinierte serialisierbare Typen byte[], Byte[], char[], Character[] Enumeration Andere Entities Collections von Entities(Collection, Set, List, Map) 98 Persistent Fields / Properties Persistent private int minr; Exemplarvariablen direkt annotiert Zugriff des Persistence-Frameworks direkt auf Variablen Vorteil: Variable und Annotation stehen direkt zusammen Persistent public int getminr{ return this.minr; get-methode wird annotiert Zugriff auf Exemplarvariablen muss immer über Standard get erfolgen (auch in der Klasse selbst) Vorteil: Flexibilität, da Methode weitere Funktionalität haben kann 99 Annotationen zur public class Mitarbeiter implements Serializable { private static final long serialversionuid = GenerationType.AUTO) private int nullable=false, updatable=true, unique=true) private String name; Wird für Objekte vorher festgehaltener Klassen definiert Entspricht einem Cache, der MANAGED-Objekte verwaltet EntityManager-Objekt für konkreten PersistenceContext EntityManager-Operationen arbeiten auf dem Cache Man muss EntityManagermitteilen, dass Daten in die DB geschrieben werden müssen em.flush(); // in Transaktion Beim Schreiben können wg. der Transaktionssteuerung der DB Exceptions auftreten (abhängig von Steuerungsart) Im Zweifel bei Entwicklung immer echte Tabellen anschauen Üblich: nur kurz lebende EntityManager(erzeugen, Aktion, schließen) 101

8 Beispiel fü r Cache ( 1 / public class Mitarbeiter implements private int //maximal zwei Zeichen private String name; public Mitarbeiter() { //leerer Konstruktor benötigt public Mitarbeiter(String name) { this.name = name; // get- und set-methoden weggelassen public String tostring(){ return name+"("+minr+")"; 102 Beispiel fü r Cache ( 2 / 2) public static void main(string[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPACachePU"); EntityManager em=emf.createentitymanager(); em.gettransaction().begin(); em.persist(new Mitarbeiter("ET")); em.persist(new Mitarbeiter("JFK")); for(int i=1;i<3;i++) System.out.println(em.find(Mitarbeiter.class,i)); em.close(); ET(1) JFK(2) org.hibernate.util.jdbcexceptionreporter logexceptions WARNUNG: SQL Error: -1, SQLState: SCHWERWIEGEND: Bei dem Versuch, VARCHAR 'JFK' auf die Länge 2 zu kürzen, ist ein Abschneidefehler aufgetreten. 103 Lebenslauf eines Entity-Objekts NEW -> merge() führt evtl. zur Mehrfachobjekterzeugung refresh() nur, wenn vorher persistiert 104 Seltsames merge public static void main(string[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPAMergePU"); EntityManager em = emf.createentitymanager(); Mitarbeiter m1 = new Mitarbeiter("Ford"); Mitarbeiter m2 = new Mitarbeiter("Arthur"); em.gettransaction().begin(); em.persist(m1); em.persist(m2); em.merge(m2); for (Mitarbeiter m : (List<Mitarbeiter>) em. createquery("select m FROM Mitarbeiter m"). getresultlist()) System.out.println(m.getMinr() + ": " + m.getname()); 1: Ford 2: Ford 3: Ford 4: Ford 5: Arthur 105

9 Wichtiges/ korrektes merge public static void main(string[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("JPAMergePU"); EntityManager em = emf.createentitymanager(); Mitarbeiter m1 = new Mitarbeiter("Ford"); em.gettransaction().begin(); em.persist(m1); Mitarbeiter m3= em.find(mitarbeiter.class,1); m1.setname("trilian"); System.out.println(m3.getMinr() + ": " + m3.getname()); // trotzdem besser: Änderungen in Transaktionen em.close(); 1: Trilian Klasse oder Tabelle? Bei der Entity-Nutzungoffen, ob erst Klassen designtund dann Tabellen entworfen werden Einfach: Tabellen existieren; dann typischerweise zur Tabelle eine Entity-Klassse erstellbar(generierbar) Wenn nichts gegeben: Entwurf der Entity-Klassen(Daten der Applikation mit ihren Abhängigkeiten) Ableitung oder Generierung der Tabellen Generierungsansätze: Drop and Create: beteiligte Tabellen löschen und neu anlegen (Entwicklung und Test) Create: wenn nicht existent, dann anlegen (Realität) None: wenn nicht existent, dann Fehler (Realität) Hinweis: bei Änderungen neu übersetzen Generelle JEE- Regel Convention over Configuration bedeutet: wenn nichts angegeben wird, wird ein Default- Wert genutzt Default-Werte sind zwar sinnvoll, sollte man aber kennen Erinnerung: Java-Inkonsistenz Einschub: XML-Konfiguration Statt Annotationen zu nutzen, können diese Informationen auch in XML beschrieben werden Typisch: einen XML-Dateipro Klasse + zusammenführende XML-Datei Vorteil: Verhaltensänderungen ohne Codeänderung Nachteil: viele kleine penibel zu pflegende Dateien Auch möglich: XML und Annotationen; dabei schlägt XML die Annotationen