Quelle est la différence entre les interfaces CrudRepository et JpaRepository dans Spring Data JPA ?
Quand je vois les exemples sur le web, je les vois là-bas de manière interchangeable.
Quelle est la différence entre eux?
Pourquoi voudriez-vous utiliser l'un sur l'autre?
Réponses:
JpaRepositorys'étend PagingAndSortingRepositoryqui à son tour s'étend CrudRepository.
Leurs fonctions principales sont:
CrudRepository fournit principalement des fonctions CRUD.PagingAndSortingRepository fournit des méthodes pour effectuer la pagination et le tri des enregistrements.JpaRepository fournit des méthodes liées à JPA telles que le vidage du contexte de persistance et la suppression d'enregistrements dans un lot.En raison de l'héritage mentionné ci-dessus, JpaRepositoryaura toutes les fonctions de CrudRepositoryet PagingAndSortingRepository. Donc, si vous n'avez pas besoin du référentiel pour avoir les fonctions fournies par JpaRepositoryet PagingAndSortingRepository, utilisez CrudRepository.
La réponse de Ken est fondamentalement juste, mais j'aimerais répondre au "pourquoi voudriez-vous utiliser l'un sur l'autre?" une partie de votre question.
L'interface de base que vous choisissez pour votre référentiel a deux objectifs principaux. Tout d'abord, vous permettez à l'infrastructure du référentiel Spring Data de trouver votre interface et de déclencher la création du proxy afin d'injecter des instances de l'interface dans les clients. Le deuxième objectif est d'intégrer autant de fonctionnalités que nécessaire dans l'interface sans avoir à déclarer de méthodes supplémentaires.
La bibliothèque principale de Spring Data est livrée avec deux interfaces de base qui exposent un ensemble dédié de fonctionnalités:
CrudRepository - Méthodes CRUDPagingAndSortingRepository- méthodes de pagination et de tri (étend CrudRepository)Les modules de magasin individuels (par exemple pour JPA ou MongoDB) exposent les extensions spécifiques au magasin de ces interfaces de base pour permettre l'accès aux fonctionnalités spécifiques au magasin comme le vidage ou le traitement par lots dédié qui prennent en compte certaines spécificités du magasin. Un exemple de ceci est deleteInBatch(…)de JpaRepositoryqui est différent delete(…)car il utilise une requête pour supprimer les entités donnée qui est plus performant , mais vient avec l'effet secondaire de ne pas déclencher les cascades de l' APP définie (comme les définit spec IT).
Nous recommandons généralement de ne pas utiliser ces interfaces de base car elles exposent la technologie de persistance sous-jacente aux clients et resserrent ainsi le couplage entre elles et le référentiel. De plus, vous vous éloignez un peu de la définition d'origine d'un référentiel qui est essentiellement "une collection d'entités". Donc, si vous le pouvez, restez avec PagingAndSortingRepository.
L'inconvénient de dépendre directement de l'une des interfaces de base fournies est double. Les deux pourraient être considérés comme théoriques, mais je pense qu'ils sont importants à connaître:
Pageou Pageabledans votre code de toute façon. Spring Data n'est pas différent de toute autre bibliothèque à usage général comme commons-lang ou Guava. Tant qu'il offre un avantage raisonnable, c'est très bien.CrudRepository, vous exposez un ensemble complet de méthodes de persistance à la fois. C'est probablement bien aussi dans la plupart des circonstances, mais vous pourriez rencontrer des situations où vous voudriez obtenir un contrôle plus fin sur les méthodes exposées, par exemple pour créer un ReadOnlyRepositoryqui n'inclut pas les méthodes save(…)et .delete(…)CrudRepositoryLa solution à ces deux inconvénients est de créer votre propre interface de référentiel de base ou même un ensemble d'entre eux. Dans de nombreuses applications, j'ai vu quelque chose comme ceci:
interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }
interface ReadOnlyRepository<T> extends Repository<T, Long> {
// Al finder methods go here
}
La première interface de référentiel est une interface de base à usage général qui ne fixe en fait que le point 1, mais lie également le type d'ID à des Longfins de cohérence. La deuxième interface a généralement toutes les find…(…)méthodes copiées CrudRepositoryet PagingAndSortingRepositoryn'expose pas les méthodes de manipulation. En savoir plus sur cette approche dans la documentation de référence .
L'abstraction du référentiel vous permet de choisir le référentiel de base totalement déterminé par vos besoins architecturaux et fonctionnels. Utilisez celles fournies hors de la boîte si elles conviennent, créez vos propres interfaces de base de référentiel si nécessaire. Éloignez-vous des interfaces de référentiel spécifiques au magasin, sauf si cela est inévitable.
Sommaire:
PagingAndSortingRepository étend CrudRepository
JpaRepository étend PagingAndSortingRepository
L' interface CrudRepository fournit des méthodes pour les opérations CRUD, elle vous permet donc de créer, lire, mettre à jour et supprimer des enregistrements sans avoir à définir vos propres méthodes.
Le PagingAndSortingRepository fournit des méthodes supplémentaires pour récupérer des entités à l'aide de la pagination et du tri.
Enfin, JpaRepository ajoute des fonctionnalités supplémentaires spécifiques à JPA.
Toutes les réponses fournissent suffisamment de détails à la question. Cependant, permettez-moi d'ajouter quelque chose de plus.
Pourquoi utilisons-nous ces interfaces:
Quelle interface fait quoi:
Quand utiliser quelle interface:
Selon http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/
Généralement, la meilleure idée est d'utiliser CrudRepository ou PagingAndSortingRepository selon que vous avez besoin de trier et de paginer ou non.
Le JpaRepository doit être évité si possible, car il relie vos référentiels à la technologie de persistance JPA, et dans la plupart des cas, vous n'utiliserez probablement même pas les méthodes supplémentaires fournies par celui-ci.
