Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Java EE 7 Grundkurs

Überblick über die JPA

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Die Java Persistence API vereinfacht es, Probleme bei der objektrelationalen Abbildung zu lösen. Dabei speichert eine in einer objektorientierten Programmiersprache erstellte Applikation sämtliche Objekte in einer relationalen Datenbank.

Transkript

Datenbankzugriffe gehören für Java EE Applikationen inzwischen genauso zum Tagesgeschäft wie dies auch bei Web- oder normalen Client-Applikationen der Fall ist. Es gibt grundsätzlich viele Möglichkeiten, auf Datenbanken zuzugreifen. Beispielsweise per JDBC, über ein Framework wie Hibernate oder mithilfe der JPA. ist die Standardschnittstelle für Datenbankzugriffe in der Java EE Und wir werden uns in diesem Video mit einigen Basics der JPA auseinandersetzen und sie einmal mit der JDBC vergleichen. Die Java Persistence API ist definiert im JSR 338. Bei der Java Persistence API handelt es sich erst mal nur um eine Spezifikation. Diese Spezifikation ist verantwortlich für Persistenz und Objekt-Relationales-Mapping. Damit wird ein Standard für die Umsetzung von Objekten auf Datenbanktabellen und zurück definiert. In der JPA sind die sogenannten CRUD-Operationen drin definiert. CRUD steht für Create, Read, Update und Delete. Das sind die Basis-Operationen, die man auf Datenbanken bzw. auf Tabellen ausführen möchte. Ebenfalls definiert die JPA eine eigene Abfragesprache auf Objekten analog zu SQL. Die JPA befasst sich sehr intensiv mit O/R-Mapping, Objekt-Relationalem Mapping. Um zu verstehen, was O/R-Mapping ist, schauen wir uns doch einfach einmal an, wie es bisher war. Wenn Sie per JDBC einen Datensatz abfragen wollten oder eine Liste von Datensätzen abfragen wollten, dann hatten Sie einiges zu tun. Dieser Beispiel-Code soll dies verdeutlichen. Es wird zunächst eine Liste erzeugt, die die Ergebnisliste halten wird. Danach wird mit Class.ForName der benötigte Treiber in den Kontext der Applikation geladen. Über den DriverManager können wir dann eine Verbindung zur Datenbank aufbauen. Anschließend erzeugen wir ein Statement. Dieses Statement nutzen wir, um die Daten zu selektieren. Es wird ein ResultSet benutzt, um diese Daten dann später zu durchlaufen. Bei jedem Durchlauf der Daten, also für jeden einzelnen Datensatz, erzeugen wir dann eine Instanz eines Objektes, was die Ergebnisse halten wird. Wir weisen jeder Eigenschaft, die wir aus der Datenbank laden, eine Eigenschaft des Objektes zu. Am Ende wird dieses Objekt in die Ergebnisliste überführt und ganz zum Schluss wird die Verbindung geschlossen. Das ist der Ansatz, wie er bei der JDBC gängig ist. JDBC steht übrigens für Java Database Connectivity API und die JDBC ist bis heute übrigens auch die Basis für den Datenbankzugriff innerhalb der JPA. Was ist schlecht an diesem Ansatz und was ist vielleicht gut daran? Nun, schlecht an dem Ansatz ist, dass wir sehr, sehr, infrastrukturell tätig sein müssen. Wir müssen die Verbindung händisch aufbauen, wir müssen die Abfrage händisch aufbauen, wir müssen das Abrufen der Daten händisch machen. Wir erledigen viele Infrastruktur- und Routinetätigkeiten. Was gut ist an diesem Ansatz ist, dass wir die Kontrolle haben. Wir definierten die SQL Statements selbst und können so genau bestimmen, was wir abrufen, wann wir es abrufen und wie wir es abrufen. Setzen wir dem den Einsatz der JPA entgegen. Hier ist es so, dass wir eine objektorientierte Abfrage machen und zwar auf Objekten vom Typ Book in diesem Beispiel. Diese Abfrage wird automatisch umgesetzt und zwar auf SQL Statements. Es wird der gesamte Infrastrukturbereich erledigt. Wir müssen uns um nichts kümmern und bekommen über die Methode getResultList der Query, die wir erzeugt haben, die Ergebnisliste zurück. Das heißt, statt dass wir gefühlt 50 Anweisungen schreiben müssen, müssen wir praktisch 2-3 Anweisungen schreiben. Was an diesem Ansatz falsch ist, kann man relativ gut und schnell erfassen, nämlich so gut wie nichts. Jedenfalls wenn wir es auf Wartbarkeit und die Menge des Codes, den wir schreiben wollen, beziehen. Was daran gut ist, ist eben, dass wir wesentlich weniger Code benötigen. Die händischen Zuweisung fallen weg und wir haben viel mehr Typsicherheit. Die SQL Statements werden automatisch generiert. Die JPA basiert ganz intensiv auf dem O/R-Mapping Ansatz. O/R-Mapping steht dabei für Objekt-Relationales-Mapping. Das bedeutet, statt wie bei der JDBC dafür verantwortlich zu sein, dass die Daten aus der Datenbank geladen und in Objekte direkt überführt werden, ist es bei JPA so, dass wir diese Aufgabe dem Framework überlassen und am Ende des Tages nur noch einzelne kleine Anweisungen haben. Die gesamte Logik zum Zugriff auf die Datenbank, zum Abrufen der Daten, zum Konvertieren der Daten wird von der JPA bzw. den unten drunter liegenden O/R-Mapping-Frameworks erledigt. Grundvoraussetzung für das O/R-Mapping ist, dass wir Entitäten definieren. Entitäten sind Komponenten, die in die Datenbank gespeichert werden. In älteren Versionen der Java EE gab es Entity Beans. Diese gibt es nicht mehr, weil Entity Beans viel zu kompliziert und umfangreich waren. Stattdessen gibt es normale POJOs. Plain Old Java Objects. Diese Plain Old Java Objects, also ganz normale Java-Klassen, sind annotieret mit der Entity Annotation. Jede Entity muss darüber hinaus über eine ID-Annotation verfügen, damit der Datensatz eindeutig zu identifizieren ist. Felder, die nicht in der Datenbank gespeichert sein sollen, werden als transient markiert. Alle als nicht transient markierten Eigenschaften werden automatisch gemapped. Und zwar wird der Feldname zum Spaltenname in der Datenbanktabelle. Diese Annotationen können auf Feldern oder auf Gettern erfolgen. Die Konvention ist, dass dies auf Feldern passiert. Die Initiierung der geladenen Daten in die dann erzeugte Entität erfolgt direkt auf Ebene vom Feld oder vom Getter. Die Sichtbarkeit ist dabei nicht wichtig. Die ganze Arbeit, die im Hintergrund stattfindet, und das ist ja nicht wenig, erledigt für uns eine EntityManager-Instanz. Auf Ebene dieser EntityManager-Instanz, die wir uns im Java EE Umfeld initiieren lassen, können wir die bereits angesprochenen CRUD-Operationen ausführen. Ebenfalls sind wir in der Lage, komplexere Abfragen zu tätigen. CRUD steht, wie bereits erwähnt, für Create, unterstützt durch die Methode persist, Read, unterstützt durch die Methoden find und execute query, Update, unterstützt durch die Methoden merge und refresh und Delete, unterstützt durch die Methode remove des EntityManagers. Wenn wir komplexere Abfragen ausführen wollen, verwenden wir die Java Persistence Query Language, JPQL. Die erlaubt es uns, Instanzen per Abfrage zu finden. Und die JPQL hat sehr, sehr viel Ähnlichkeit mit SQL, mit der Structured Query Language, die normalerweise auf Ebene von Datenbanken eingesetzt wird. Aber, die JPQL arbeitet ausschließlich auf Objekten. Das bedeutet, dass wir als Entwickler die Schere im Kopf, die wir oftmals haben müssen, Objekte auf der einen Seite, Datenbanken und Datenbankstrukturen auf der anderen Seite, verlieren können. Die JPQL ist eine sehr leistungsfähige Sprache. Sie kennt Joins und sie kennt sogenannte Constructor Queries. Constructor Queries sind Abfragen, mit denen sich neue Instanzen erzeugen lassen von Objekten, die eigentlich gar nicht unter Verwaltung der JPA stehen. So ein JPQL Statement kann aussehen, wie dieses Statement und das ist letztlich etwas, was man als jemand, der möglicherweise schon einmal mit SQL gearbeitet hat, durchaus leicht verstehen kann. Wie gesagt, einziger und dafür aber gewaltiger Unterschied ist, dass solche Statements auf Objekten fungieren. Das heißt, Book ist in diesem Fall keine Datenbanktabelle, sondern ein Objekt. In diesem Video haben wir ein wenig über das, was hinter der JPA steht, gesprochen. Wir haben geklärt, was O/R-Mapping ist und wie sich die JPA von JDBC unterscheidet. Dieses Wissen gilt es nun zu vertiefen.

Java EE 7 Grundkurs

Lernen Sie die Grundlagen der Programmierung mit Java EE 7 verstehen und anwenden.

6 Std. 4 min (44 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!