Was bisher geschah
Teil 1: Spring Data Commons
Teil 2: Spring Data JPA
Nachdem wir im ersten Teil dieser Blog-Serie das Spring Data Commons Projekt vorgestellt haben, wollen wir nun das Unterprojekt Spring Data JPA genauer unter die Lupe nehmen.
JPA
JPA ist als Teil des JEE -Stacks eine standardisierte Schnittstelle, mit der POJOs in relationalen Datenbanksystemen persistiert werden können. Mit einer eigenen Abfragesprache JPQL können Datenbankabfragen unabhängig von einem konkreten SQL-Dialekt formuliert werden. Für das Verständnis von Spring Data JPA sollten daher zumindest Grundkenntnisse des JPA API s vorhanden sein.
Spring Data JPA
Aufbauend auf dem klassischen JPA Support bietet Spring Data JPA (u.a.) ein Konzept, mit dem JPQL-Queries wesentlich einfacher implementiert werden können. Üblicherweise sind Queries parametrisiert. Vor der Ausführung einer Query schreibt der Entwickler meistens eine Menge Boilerplate-Code, um diese Parameter zu setzen. Das wird dann klassich in einem Spring-Repository in etwa so implementiert:
Dieser Code lässt sich durch Nutzung des Fluent Intefaces von TypedQuery zwar noch etwas kompakter formulieren …
… dennoch schreibt man für jede Datenbankabfrage immer wieder eine Methode, die eine Liste von Parameter entgegennimmt, diese in die Query einsetzt und schließlich die Query ausführt. Mit Spring Data JPA lässt sich das wesentlich eleganter formulieren:
Die Grundidee ist die, dass man bereits aus der Signatur einer Interface(!)-Methode den bzw. die Namen des/der Query-Parameter ableiten kann. Spring liefert zur Laufzeit eine entsprechende Implementierung, die die entsprechende Query über das JPA Criteria API aufbaut und auch ausführt. Damit ist ein Großteil von Queries in der Praxis sehr schnell formuliert. Dieser Mechanismus läßt sich mit den allgemeinen Sortierungs- und Paginations -Aspekten kombinieren:
Ein weiterer Unterschied zur klassischen JPA-Entwicklung stellt die Möglichkeit dar, JPQL-Queries als Annotation an die Query-Methode zu schreiben. Üblicherweise werden die Queries mittels der @NamedQuery an die JPA-Entity annotiert und müssen über einen symbolischen Namen aufgefunden werden. Dies ist mit Spring Data JPA nicht notwendig, da die Query direkt an die Repository-Methode annotiert wird:
Ich persönlich finde diesen Ansatz sehr gelungen, da auf diese Weise die Query dort formuliert wird, wo sie auch verwendet wird und nicht die JPA-Entität zumüllt.
Eine weitere nette Eigenschaft ist die, dass die Queries bereits beim Aufbau des Application Context validiert werden. So werden Syntax-Fehler in JPQL-Queries schnell gefunden. Dies geschieht bei Verwendung des reinen JPA APis sonst erst zur Laufzeit.
Beispiel
Den kompletten Source-Code findet man als Maven-Projekt auf Github . Zur Ausführung der Beispiele verwenden wir OpenJPA als JPA-Provider und HyperSQL DB als RDBMS. Der Unit-Test jpa.JpaRepoTest ist ein guter Startpunkt.
Wesentlich ist, dass man konfiguriert, aus welcher Paketstruktur die Repository-Interfaces automagisch JPA-fiziert werden sollen:
Bei mehr als einer verwendeten EntityManagerFactory kann man angeben, welche konkrete Factory die Repositories verwenden sollen.
Was gibt’s sonst noch?
Wie im ersten Teil der Blog-Serie angekündigt, habe ich nur einige Aspekte von Spring Data JPA vorgestellt. Eine vollständige Feature-Liste findet man auf der Homepage des Projekts .
Ausblick
Die Projekte Spring Data MongoDB oder Spring Data Neo4J sind gute Kandidaten für weitere Beiträge in dieser Serie.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Trelle
17.12.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Trelle
Software Architect
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.