Spring Data – Repositories & Query Methods

Das Spring Framework bietet seit Anbeginn Möglichkeiten ohne große Komplexität oder Aufwand die eigene Anwendung an einen Datenspeicher anzubinden.
Mit Konstrukten wie dem

- oder

konnte man auf relationale Datenbanken zugreifen und Daten in diesen ablegen.
Mit dem Aufkommen der NoSQL-Datenspeicher stieg die Anzahl an zu unterstützenden Mechanismen enorm an. Um diesen Bedarf gerecht zu werden, wurde das Spring Data Schirm-Projekt eingeführt. Dort werden die Aktivitäten in Bezug auf Datenspeicher-Technologien gebündelt.

Das Projekt umfasst derzeit folgende offizielle Module:

  • JPA (Relationale Datenbanken)
  • MongoDB
  • Neo4J
  • Redis
  • Solr
  • Hadoop
  • Gemfire
  • JDBC Extensions

Zusätzlich werden durch die Community die Module Couchbase, ElasticSearch, Cassandra und DynamoDB bereitgestellt.

Repositories

Das markanteste Feature von Spring Data ist sicherlich die Repository-Abstraction. Man definiert lediglich ein Interface und gibt durch Generics an auf welche Entität, Dokument etc. sich dieses Repository bezieht. Zusätzlich bestimmt man durch die Wahl des Eltern-Interface über welche Funktionalitäten das Repository bereits verfügen soll.

Sofern ein Modul die Repository-Abstraction unterstützt gibt es für dieses Modul ein entsprechendes Interface das neben Grund-Funktionalitäten wie findOne, findAll, delete und save mit spezifischen Funktionalitäten für den verwendeten Datenspeicher ausgestattet ist. Das im Beispiel verwendete MongoRepository bietet neben den angesprochenen CRUD-Operationen auch Methoden an, die einen

- oder

-Parameter akzeptieren.

Die definierten Repositories dienen Spring Data als Rezept um eine Instanz (genauer ein Proxy-Objekt) zu erzeugen. Dieses delegiert die Aufrufe an eine Referenz-Implementierung bei der die den Basis-Interfaces definierten Funktionalitäten implementiert sind.

Nun sollte man sich fragen, warum die Definition eines Interfaces und das Instantiieren eines Proxy-Objekts notwendig ist, wenn es doch bereits eine Referenz-Implementierung gibt, die alle Funktionalitäten bereitstellt. Oftmals hat eine Anwendung nicht immer das Recht Daten in einen Datenspeicher zu schreiben oder Daten aus einem solchen zu lesen. Oder man möchte nur eine eine Mixtur aus Lösch- und Speicher-Funktionalität bereitstellen. Um nun nicht die Gefahr einzugehen, dass jemand genau diese nicht erlaubten oder nicht gewünschten Operationen ausführt, können die Interfaces entsprechend definiert werden. Bei einer Klasse ist man eingeschränkt welche Funktionalität man anbietet, ohne dabei eine mehrstufige Hierarchie aufbauen zu müssen. Eine Mixtur (Mixin) ist, zumindest unter Java, mit immensem Aufwand verbunden, da sämtliche Kombinationen in Betracht gezogen werden müssten.

Der von Spring Data verwendete Mechanismus erlaubt die einfache Definition einer solchen Mixtur. Es müssen lediglich die Methoden-Signatur der gewünschten Funktionalität in das eigene Repository kopiert werden. Wichtig ist, dass das eigene Repository von einem der Basis-Interfaces erbt (

,

usw.).

dient Spring Data als Markierung und muss, falls die anderen Basis-Interface nicht geneignet sind, als Basis-Interface angegeben werden.

Paging & Sorting

Das Basis-Interface

erlaubt es beim Abfragen der Ergebnisse die Menge dieser zu beschränken. Dazu definiert das Interface jeweils Methode die einen

-Parameter bzw. einen

-Parameter akzeptiert. Über

kann gesteuert werden nach welcher Eigenschaft die Ergebnis-Menge sortiert ist. Mit

kann die Ergebnis-Menge eingeschränkt und ein Offset definiert werden. Zusätzlich hat

auch eine

-Eigenschaft.
Das Beispiel unten zeigt wie man mit

eine sortierte Liste abfragt. Die Parameter von Pageable sind: Seite, Anzahl Elemente, die Richtung in der sortiert werden soll und die Attribute nach denen sortiert werden soll. Pro Iteration werden immer 10 Personen aus der Datenbank geladen, bis es keine weiteren Einträge mehr gibt.

Dieses Feature ist vor allem für Web-Anwendungen die über eine Seitennavigation verfügen oder Inhalte stückchenweise laden geeignet. In Kombination mit Spring MVC kann das

-Objekt direkt aus den Parametern des HTTP-Request erstellt werden. Siehe Spring Data – Web Support.

Query Methods

Oftmals reicht die von den Basis-Interfaces bereitgestellte Abfrage-Funktionalität nicht aus und man muss eigene Abfragen definieren. Die Verwendung von Interfaces beschränkt die Möglichkeit eine eigene Methode für die Abfrage zu definieren stark. Um dennoch die eigene Abfrage deklarieren zu können, bietet die Repository-Abstraction drei Optionen. Die erste Möglichkeit stellt die Definition von sogenannten Query Methods dar. Dabei definiert man eine Methode die einem festen Namenschema folgt. Query Methods beginnen mit „findBy“ gefolgt von einem Attribut-Namen der Entität, Dokuments etc., und optional einer Relation (z.B. In oder Like). Weitere Attribute können mit And oder Or angehangen werden. Für jedes Attribut muss ein Methoden-Parameter existieren.
Die Repository-Abstraction erzeugt aus dem Methodennamen eine für die verwendete Technologie gültige Abfrage. Das folgende Beispiel zeigt welche JPQL-Abfrage aus der definierten Methode resultiert.

Für den Fall, dass die Abfrage etwas komplexer ist, kann die Methode mit

annotiert werden. Als Wert muss eine gültige Abfrage für die jeweils gewählte Technologie angegeben werden.

Diese Methoden können mit einem

oder

-Parameter versehen werden. Dieser wird auf die Abfrage angewandt.

Custom Repository

Sollten die oben genannten Möglichkeiten nicht für den Anwendungsfall genügen, kann eine eigene Methode implementiert werden. Damit dies funktioniert müssen einige Konventionen eingehalten werden.

  1. Die zu implementierende Methode muss in einem separaten Interface definiert werden
  2. Das eigentlich Repository muss dieses Interface erweitern ( )
  3. Es existiert eine Klasse mit dem Namen des Repository und dem Zusatz Impl
  4. Die Klasse implementiert das zusätzliche Interface

Das folgende Beispiel zeigt das

mit der Erweiterung

und der Implementierung.

Alle hier angesprochenen Features können in der Referenz von Spring Data nachgeschlagen werden und sind dort weitreichend beschrieben. In den nächsten Beiträgen zu Spring Data werde ich auf die einzelnen Module eingehen und mich deren Besonderheiten und möglichen Anwendungsszenarien widmen. Zudem zeige ich, wie die Anwendung konfiguriert werden muss, damit Spring Data verwendet werden kann.

Das könnte Dich auch interessieren...

1 Antwort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen