it-swarm.com.de

Was ist der Unterschied zwischen CrudRepository- und JpaRepository-Schnittstellen in Spring Data JPA?

Was ist der Unterschied zwischen CrudRepository und JpaRepository Schnittstellen in Spring Data JPA?

Wenn ich die Beispiele im Web sehe, sehe ich, dass sie irgendwie austauschbar sind. Was ist der Unterschied zwischen ihnen? Warum solltest du eins übereinander verwenden?

541
kseeker

JpaRepository erweitert PagingAndSortingRepository , was wiederum CrudRepository erweitert.

Ihre Hauptfunktionen sind:

  • CrudRepository bietet hauptsächlich CRUD-Funktionen.
  • PagingAndSortingRepository bietet Methoden zum Paginieren und Sortieren von Datensätzen.
  • JpaRepository stellt einige JPA-bezogene Methoden bereit, z. B. das Leeren des Persistenzkontexts und das Löschen von Datensätzen in einem Stapel.

Aufgrund der oben erwähnten Vererbung verfügt JpaRepository über alle Funktionen von CrudRepository und PagingAndSortingRepository. Wenn Sie das Repository nicht benötigen, um die von JpaRepository und PagingAndSortingRepository bereitgestellten Funktionen zu haben, verwenden Sie CrudRepository.

762
Ken Chan

Kens Antwort ist im Grunde genommen richtig, aber ich würde gerne die Frage beantworten, warum Sie eine über die andere verwenden möchten. Teil Ihrer Frage.

Grundlagen

Die Basisschnittstelle, die Sie für Ihr Repository auswählen, dient hauptsächlich zwei Zwecken. Zunächst ermöglichen Sie der Spring Data-Repository-Infrastruktur, Ihre Schnittstelle zu finden und die Proxy-Erstellung auszulösen, sodass Sie Instanzen der Schnittstelle in Clients einspeisen. Der zweite Zweck besteht darin, so viele Funktionen wie nötig in die Schnittstelle zu integrieren, ohne zusätzliche Methoden deklarieren zu müssen.

Die gemeinsamen Schnittstellen

Die Spring Data-Kernbibliothek wird mit zwei Basisschnittstellen ausgeliefert, die eine Reihe von Funktionen bereitstellen:

  • CrudRepository - CRUD-Methoden
  • PagingAndSortingRepository - Methoden zum Paginieren und Sortieren (erweitert CrudRepository)

Filialspezifische Schnittstellen

Die einzelnen Geschäftsmodule (z. B. für JPA oder MongoDB) stellen geschäftsspezifische Erweiterungen dieser Basisschnittstellen bereit, um den Zugriff auf geschäftsspezifische Funktionen wie das Leeren oder das dedizierte Batching zu ermöglichen, die einige Geschäftsspezifikationen berücksichtigen. Ein Beispiel hierfür ist deleteInBatch(…) von JpaRepository, das sich von delete(…) unterscheidet, da eine Abfrage zum Löschen der angegebenen Entitäten verwendet wird, die leistungsstärker ist, aber den Nebeneffekt hat, dass die JPA nicht ausgelöst wird -definierte Kaskaden (wie es die Spezifikation definiert).

Im Allgemeinen empfehlen wir , diese Basisschnittstellen nicht zu verwenden , da sie die zugrunde liegende Persistenztechnologie für die Clients verfügbar machen und somit die Kopplung zwischen ihnen und dem Repository festigen. Außerdem weicht man ein bisschen von der ursprünglichen Definition eines Repositorys ab, das im Grunde "eine Sammlung von Entitäten" ist. Also, wenn Sie können, bleiben Sie bei PagingAndSortingRepository.

Benutzerdefinierte Repository-Basisschnittstellen

Die Kehrseite der direkt von einer der bereitgestellten Basisschnittstellen abhängigen ist zweifach. Beide können als theoretisch angesehen werden, aber ich denke, dass es wichtig ist, Folgendes zu beachten:

  1. Abhängig von einer Spring Data-Repository-Schnittstelle wird die Repository-Schnittstelle mit der Bibliothek gekoppelt. Dies ist meines Erachtens kein besonderes Problem, da Sie wahrscheinlich Abstraktionen verwenden werden wie Page oder Pageable in Ihrem Code trotzdem. Spring Data unterscheidet sich nicht von anderen Allzweckbibliotheken wie commons-lang oder Guava. Solange es einen angemessenen Nutzen bietet, ist es in Ordnung.
  2. Indem z.B. CrudRepository, stellen Sie eine vollständige Reihe von Persistenzmethoden auf einmal zur Verfügung. Dies ist wahrscheinlich auch in den meisten Fällen in Ordnung, aber Sie könnten in Situationen geraten, in denen Sie mehr Geld verdienen möchten gezielte Kontrolle über die Methoden aussetzen, z um ein ReadOnlyRepository zu erstellen, das die save(…) und delete(…) Methoden von CrudRepository nicht enthält.

Die Lösung für beide Nachteile besteht darin, eine eigene Basis-Repository-Schnittstelle oder sogar einen Satz davon zu erstellen. In vielen Anwendungen habe ich so etwas gesehen:

interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }

interface ReadOnlyRepository<T> extends Repository<T, Long> {

  // Al Finder methods go here
}

Die erste Repository-Schnittstelle ist eine universelle Basisschnittstelle, die eigentlich nur Punkt 1 behebt, aber den ID-Typ aus Konsistenzgründen mit Long verknüpft. In der zweiten Schnittstelle werden normalerweise alle find…(…) -Methoden aus CrudRepository und PagingAndSortingRepository kopiert, die manipulierenden werden jedoch nicht verfügbar gemacht. Lesen Sie mehr zu diesem Ansatz in der Referenzdokumentation .

Zusammenfassung - tl; dr

Mit der Repository-Abstraktion können Sie das Basis-Repository auswählen, das vollständig von Ihren architektonischen und funktionalen Anforderungen bestimmt wird. Verwenden Sie die mitgelieferten, sofern sie passen, und stellen Sie bei Bedarf Ihre eigenen Repository-Basisschnittstellen her. Halten Sie sich von den speicherspezifischen Repository-Schnittstellen fern, sofern dies nicht unvermeidbar ist.

352
Oliver Drotbohm

enter image description here

Zusammenfassung:

  • PagingAndSortingRepository erweitert CrudRepository

  • JpaRepository erweitert PagingAndSortingRepository

Die Schnittstelle CrudRepository bietet Methoden für CRUD-Operationen, sodass Sie Datensätze erstellen, lesen, aktualisieren und löschen können, ohne eigene Methoden definieren zu müssen.

Das PagingAndSortingRepository bietet zusätzliche Methoden zum Abrufen von Entitäten mithilfe von Paginierung und Sortierung.

Schließlich fügt das JpaRepository weitere Funktionen hinzu, die für JPA spezifisch sind.

59

Ich lerne Spring Data JPA. Es könnte Ihnen helfen: enter image description here

3
Feng Zhang