JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile

Weniger Code, mehr Spaß

Spring Data, JPA 2 und Querydsl

Weniger Code, mehr Spaß

jochen mader

Die Kombination von Querydsl und Spring Data ist derzeit konkurrenzlos. Kein anderes Framework schafft es, die Menge an Boilerplate-Code so konsequent zu reduzieren und dabei ein so elegantes API bereitzustellen. Getreu dem Prinzip: „Die beste Zeile Code ist die, die man erst gar nicht schreibt“ enthalten Repositories am Ende nur das, was sie auch wirklich brauchen. Für den Entwickler bedeutet das: mehr Spaß bei der Arbeit mit relationalen Datenbanken.

Ziel dieses Artikels ist, zu zeigen, wie die Verwendung von Spring Data in Verbindung mit JPA 2 und Querydsl das Leben extrem erleichtern kann. Vorausgesetzt wird, dass man weiß, wie man einen ORM (Object Relational Mapper) aufsetzt und die Konzepte hinter JPA 2 (Annotationen, EntityManager usw.) beherrscht. Den vollständigen Code zu diesem Artikel samt der zugehörigen ORM-Konfiguration findet man auf GitHub [1].

ORMs sind nicht aus der Softwareentwicklung wegzudenken. In Sachen Performance und Verwendung von speziellen DB-Features hat sich hier einiges getan. Auf der Strecke blieben dabei notwendige Weiterentwicklungen des API. Es mag ein subjektiver Eindruck sein, aber seit einer gefühlten Ewigkeit waren wir gezwungen, Mapping-Informationen in XML-Dateien abzulegen und Querys mühsam per Hand zu schreiben und zu pflegen.

Typsicherheit war hier schon immer ein Fremdwort, und die Unmengen an Boilerplate-Code waren nur schwer zu verstecken. Ständig hat man aus älteren Projekten DAO-Implementierungen kopiert oder sich zum x-ten Mal über einen Tippfehler in der Query geärgert.

Zugegeben, die Sache mit den XML-Mapping-Informationen sind wir mittlerweile losgeworden, auch wenn es immer noch genügend Leute gibt, die sich dagegen wehren. Die fehlende Typsicherheit ist das größte Problem. Egal, wie intelligent eine IDE mit der Erzeugung einer Query umgeht, er bleibt ein String, und Probleme werden im schlimmsten Fall erst erkannt, wenn es schon zu spät ist. Wer jetzt das Criteria-API anführen möchte, sei auf später vertröstet. 

Spring Data

Bei Spring Data handelt es sich um ein „Umbrella“-Projekt ähnlich Spring Security oder Spring Social. Ziel war es, die Verwendung verschiedenster Data Stores so einfach wie möglich zu gestalten, ohne dabei Funktionalitäten zu beschränken. Dabei legte man besonderen Wert darauf, die Unterschiede der Stores nicht zu verwischen. Schließlich möchte man keine relationale Algebra auf Neo4j abbilden, sondern mit Graphen arbeiten.

Das so entstandene Projekt bietet Anbindungen für verschiedenste dokumentorientierte Datenbanken, Key-Value Stores und andere alternative Konzepte. Daneben hat man auch daran gedacht, sich um den immer noch dominantesten Anteil unter den Data Stores zu kümmern: die relationale Datenbank.

Spring Data JPA

ORM ist für viele Datenbankanwendungen das Mittel der Wahl, wenn es darum geht, von Java aus mit einer DB zu interagieren. Über den richtigen ORM lässt sich vortrefflich streiten. Glücklicherweise will sich Spring Data in diese Diskussion nicht einmischen. Man setzte auf die Verwendung von JPA 2 als Basis. Durch diesen Standard war es möglich, fast vollkommen unabhängig von einer konkreten Implementierung zu bleiben. JPA 2 ist aber bei Weitem nicht perfekt, und man ist immer noch an einigen Ecken dazu gezwungen, Vendor-Erweiterungen zu verwenden. Für die Aufgaben von Spring Data benötigt man aber keine davon.

Mehr aus dieser Ausgabe

Artikel erschienen in

In jedem neuen Softwareprojekt wird, oder zumindest sollte es so sein, der…
Android Tutorial
Wir stellen Ihnen die Rezeptur und die Zutaten zur Verfügung, Sie kümmern sich…
jochen mader
Die Kombination von Querydsl und Spring Data ist derzeit konkurrenzlos. Kein…
Java auf dem Raspberry Pi, Java auf dem LEGO MINDSTORMS NXT Controller. Doch…
christian meder
Die Google I/O 2013 kam und ging ohne die Vorstellung neuer, spektakulärer…
Ein herzliches Grüß Gott zu einer weiteren Ausgabe der Java-Magazin-…
©Shutterstock/	natalia bulatova
In jedem neuen Softwareprojekt wird, oder zumindest sollte es so sein, der…
 

Kommentare

von Lukas Eder (Unveröffentlicht) am
Konkurrenzlos, vorausgesetzt JPA ist zwingend gesetzt. Wer lieber SQL schreiben möchte ist mit jOOQ unter Umständen besser bedient: http://www.jooq.org

von Oliver Gierke (Unveröffentlicht) am
Die im Artikel beschriebene Unterstützung gibt es auch für Persistenztechnologien ungleich JPA. Im NoSQL Umfeld gibt es bereits Pivtoal getriebene Module für MongoDB, Neo4j und Gemfire, sowie von der Community geleitete für Solr, Elasticsearch und Couchbase. Selbst für reines JDBC gibt es im Spring Data JDBC Modul Unterstützung dafür SQL queries mithilfe von Querydsl komplett typsicher schreiben zu können [0]. Gruß, Ollie Project lead, Spring Data JPA [0] https://github.com/SpringSource/spring-data-jdbc-ext/blob/master/spring-data-jdbc-core/src/test/java/org/springframework/data/jdbc/query/QueryDslTemplateTest.java

von Lukas Eder (Unveröffentlicht) am
Hallo Oliver, ich bin ja mal wirklich gespannt, wie dieser "Query-it-all" Ansatz langfristig bei den Nutzern ankommt. Dass eine SQL-inspirierte Abfragesprache für alle Datastores nicht unbedingt die am besten geeignete Technik ist, hat sich bereits bei LINQ-to-SQL gezeigt. Es ist natürlich klar, dass Spring Data überall die Finger drin haben will :-). Aber ich denke, diese Architekturen zielen an den Bedürfnissen der Nutzer vorbei und führen nur den nächsten "Impedance Mismatch" ein.

von Jochen Mader (Unveröffentlicht) am
Nicht Spring Data und QueryDSL durcheinander bekommen. Spring Data ist ein reiner Repository-Layer in dem du verwenden kannst was du willst. Entweder die native Abfragesprache oder eben QueryDSL.

Seiten

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).