Qual è la differenza tra le interfacce CrudRepository e JpaRepository in Spring Data JPA ?
Quando vedo gli esempi sul web, li vedo lì usati in modo intercambiabile.
Qual'è la differenza tra loro?
Perché vorresti usarne uno sopra l'altro?
Risposte:
JpaRepositorysi estende PagingAndSortingRepositoryche a sua volta si estende CrudRepository.
Le loro funzioni principali sono:
CrudRepository fornisce principalmente funzioni CRUD.PagingAndSortingRepository fornisce metodi per eseguire l'impaginazione e l'ordinamento dei record.JpaRepository fornisce alcuni metodi correlati a JPA come svuotare il contesto di persistenza ed eliminare i record in un batch.A causa dell'eredità di cui sopra, JpaRepositoryavrà tutte le funzioni di CrudRepositorye PagingAndSortingRepository. Quindi, se non hai bisogno del repository per avere le funzioni fornite da JpaRepositorye PagingAndSortingRepository, usa CrudRepository.
La risposta di Ken è fondamentalmente giusta, ma mi piacerebbe avanzare sul "perché dovresti usarne uno sopra l'altro?" parte della tua domanda.
L'interfaccia di base scelta per il repository ha due scopi principali. Innanzitutto, consenti all'infrastruttura del repository Spring Data di trovare la tua interfaccia e di attivare la creazione del proxy in modo da iniettare istanze dell'interfaccia nei client. Il secondo scopo è quello di inserire tutte le funzionalità necessarie nell'interfaccia senza dover dichiarare metodi extra.
La libreria principale di Spring Data viene fornita con due interfacce di base che espongono un set dedicato di funzionalità:
CrudRepository - Metodi CRUDPagingAndSortingRepository- metodi per l'impaginazione e l'ordinamento (estende CrudRepository)I singoli moduli del negozio (ad es. Per JPA o MongoDB) espongono le estensioni specifiche del negozio di queste interfacce di base per consentire l'accesso a funzionalità specifiche del negozio come lo svuotamento o il batch dedicato che tengono conto di alcune specifiche del negozio. Un esempio di questo è deleteInBatch(…)di JpaRepositorydiverso da delete(…)quanto utilizza una query per eliminare le entità indicate che è più performante ma viene con l'effetto collaterale di non innescare cascate APP-definito (come le definisce Spec it).
In genere si consiglia di non utilizzare queste interfacce di base in quanto espongono la tecnologia di persistenza sottostante ai client e stringono quindi l'accoppiamento tra loro e il repository. Inoltre, ti allontani un po 'dalla definizione originale di un repository che è fondamentalmente "una raccolta di entità". Quindi, se puoi, resta con PagingAndSortingRepository.
L'aspetto negativo di dipendere direttamente da una delle interfacce di base fornite è duplice. Entrambi potrebbero essere considerati teorici, ma penso che siano importanti essere consapevoli di:
Pageo Pageablenel tuo codice. Spring Data non è diverso da qualsiasi altra libreria di uso generale come commons-lang o Guava. Finché fornisce un vantaggio ragionevole, va bene.CrudRepository, ad esempio , si espone contemporaneamente un set completo di metodi di persistenza. Questo probabilmente va bene anche nella maggior parte dei casi, ma potresti imbatterti in situazioni in cui desideri ottenere un controllo più approfondito sui metodi esposti, ad esempio per creare un metodo ReadOnlyRepositoryche non include i metodi save(…)e .delete(…)CrudRepositoryLa soluzione a entrambi questi aspetti negativi è creare la propria interfaccia di repository di base o anche un set di essi. In molte applicazioni ho visto qualcosa del genere:
interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }
interface ReadOnlyRepository<T> extends Repository<T, Long> {
// Al finder methods go here
}
La prima interfaccia del repository è un'interfaccia di base per scopi generici che in realtà risolve solo il punto 1 ma lega anche il tipo ID Longper coerenza. La seconda interfaccia di solito ha tutti i find…(…)metodi copiati CrudRepositorye PagingAndSortingRepositorynon espone quelli manipolatori. Maggiori informazioni su tale approccio nella documentazione di riferimento .
L'astrazione del repository ti consente di scegliere il repository di base totalmente guidato dalle tue esigenze architettoniche e funzionali. Se necessario, usa quelli forniti immediatamente, crea le interfacce di base del repository, se necessario. Stare lontano dalle interfacce del repository specifico del negozio a meno che non sia inevitabile.
Sommario:
PagingAndSortingRepository estende CrudRepository
JpaRepository estende PagingAndSortingRepository
L' interfaccia di CrudRepository fornisce metodi per le operazioni CRUD, quindi consente di creare, leggere, aggiornare ed eliminare i record senza dover definire i propri metodi.
Il PagingAndSortingRepository fornisce ulteriori metodi per recuperare le entità che utilizzano l'impaginazione e di ordinamento.
Infine, JpaRepository aggiunge alcune funzionalità specifiche di JPA.
Tutte le risposte forniscono dettagli sufficienti alla domanda. Tuttavia, vorrei aggiungere qualcosa di più.
Perché stiamo usando queste interfacce:
Quale interfaccia fa cosa:
Quando utilizzare quale interfaccia:
Secondo http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/
Generalmente l'idea migliore è quella di utilizzare CrudRepository o PagingAndSortingRepository a seconda che siano necessari l'ordinamento e il paging o meno.
Il JpaRepository dovrebbe essere evitato, se possibile, perché lega i repository alla tecnologia di persistenza JPA e nella maggior parte dei casi probabilmente non useresti nemmeno i metodi extra forniti da esso.
