Was ist der Unterschied zwischen CrudRepository- und JpaRepository- Schnittstellen in Spring Data JPA ?
Wenn ich die Beispiele im Web sehe, sehe ich, dass sie dort austauschbar verwendet werden.
Was ist der Unterschied zwischen ihnen?
Warum sollten Sie einen über den anderen verwenden wollen?
Antworten:
JpaRepositoryerstreckt sich, PagingAndSortingRepositorywas sich wiederum erstreckt CrudRepository.
Ihre Hauptfunktionen sind:
CrudRepository bietet hauptsächlich CRUD-Funktionen.PagingAndSortingRepository Bietet Methoden zum Paginieren und Sortieren von Datensätzen.JpaRepository bietet einige JPA-bezogene Methoden wie das Leeren des Persistenzkontexts und das Löschen von Datensätzen in einem Stapel.Aufgrund der oben erwähnten Vererbung JpaRepositorywerden alle Funktionen von CrudRepositoryund PagingAndSortingRepository. Wenn Sie das Repository also nicht benötigen, um die von JpaRepositoryund bereitgestellten Funktionen zu haben PagingAndSortingRepository, verwenden Sie CrudRepository.
Kens Antwort ist im Grunde richtig, aber ich würde gerne sagen: "Warum sollten Sie eine über die andere verwenden?" Teil Ihrer Frage.
Die Basisschnittstelle, die Sie für Ihr Repository auswählen, dient zwei Hauptzwecken. Zunächst erlauben Sie der Spring Data-Repository-Infrastruktur, Ihre Schnittstelle zu finden und die Proxy-Erstellung auszulösen, sodass Sie Instanzen der Schnittstelle in Clients einfügen. 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 Spring Data-Kernbibliothek wird mit zwei Basisschnittstellen geliefert, die eine Reihe dedizierter Funktionen bereitstellen:
CrudRepository - CRUD-MethodenPagingAndSortingRepository- Methoden zur Paginierung und Sortierung (erweitert CrudRepository)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 Flushing oder dedizierte Stapelverarbeitung zu ermöglichen, die einige Geschäftsspezifikationen berücksichtigen. Ein Beispiel dafür ist , deleteInBatch(…)von JpaRepositorydenen verschieden ist , delete(…)da es eine Abfrage verwendet die gegebenen Einheiten zu löschen , die leistungsfähiger ist , sondern kommt mit der Nebenwirkung der nicht die JPA-definierten Kaskaden Triggern (wie die Spezifikation definiert es).
Wir empfehlen im Allgemeinen , diese Basisschnittstellen nicht zu verwenden, da sie den Clients die zugrunde liegende Persistenztechnologie zugänglich machen und somit die Kopplung zwischen ihnen und dem Repository enger machen. Außerdem entfernen Sie sich ein wenig von der ursprünglichen Definition eines Repositorys, bei dem es sich im Grunde um eine "Sammlung von Entitäten" handelt. Also, wenn du kannst, bleib bei PagingAndSortingRepository.
Der Nachteil von direkt abhängig von einer der bereitgestellten Basisschnittstellen ist zweifach. Beide mögen als theoretisch angesehen werden, aber ich denke, es ist wichtig, sich dessen bewusst zu sein:
Pageoder Pageablein Ihrem Code verwenden werden. Spring Data unterscheidet sich nicht von anderen Universalbibliotheken wie Commons-Lang oder Guava. Solange es einen angemessenen Nutzen bietet, ist es in Ordnung.CrudRepository, legen Sie sofort einen vollständigen Satz von Persistenzmethoden offen. Dies ist wahrscheinlich auch in den meisten Fällen in Ordnung, aber Sie könnten auf Situationen stoßen, in denen Sie eine genauere Kontrolle über die verfügbaren Methoden erlangen möchten, z. B. um eine zu erstellen ReadOnlyRepository, die die save(…)und delete(…)Methoden von nicht enthält CrudRepository.Die Lösung für diese beiden Nachteile besteht darin, eine eigene Basis-Repository-Schnittstelle oder sogar eine Reihe 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 Allzweck-Basisschnittstelle, die eigentlich nur Punkt 1 behebt, aber auch den ID-Typ Longaus Konsistenzgründen verknüpft. Die zweite Schnittstelle hat in der Regel alle find…(…)kopierten Methoden CrudRepositoryund PagingAndSortingRepositoryaber nicht die Manipulation von der nicht aussetzen. Weitere Informationen zu diesem Ansatz finden Sie in der Referenzdokumentation .
Mit der Repository-Abstraktion können Sie das Basis-Repository auswählen, das vollständig von Ihren architektonischen und funktionalen Anforderungen abhängt. Verwenden Sie die im Lieferumfang enthaltenen, falls zutreffend, und erstellen Sie bei Bedarf Ihre eigenen Repository-Basisschnittstellen. Halten Sie sich von den geschäftsspezifischen Repository-Schnittstellen fern, sofern dies nicht unvermeidbar ist.
Zusammenfassung:
PagingAndSortingRepository erweitert CrudRepository
JpaRepository erweitert PagingAndSortingRepository
Die CrudRepository- Schnittstelle bietet Methoden für CRUD-Operationen, sodass Sie Datensätze erstellen, lesen, aktualisieren und löschen können, ohne Ihre eigenen 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 einige weitere Funktionen hinzu, die für JPA spezifisch sind.
Alle Antworten enthalten ausreichende Details zur Frage. Lassen Sie mich jedoch noch etwas hinzufügen.
Warum verwenden wir diese Schnittstellen:
Welche Schnittstelle macht was:
Wann welche Schnittstelle verwendet werden soll:
Laut http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/
Im Allgemeinen ist es am besten, CrudRepository oder PagingAndSortingRepository zu verwenden, je nachdem, ob Sie sortieren und pagen müssen oder nicht.
Das JpaRepository sollte nach Möglichkeit vermieden werden, da es Ihre Repositorys an die JPA-Persistenztechnologie bindet und Sie in den meisten Fällen wahrscheinlich nicht einmal die von ihr bereitgestellten zusätzlichen Methoden verwenden würden.
