Quelle est la différence entre les interfaces CrudRepository et JpaRepository dans Spring Data JPA ?

Question

Quelle est la différence entre CrudRepository y JpaRepository interfaces dans Spring Data JPA ?

Quand je vois les exemples sur le web, je les vois utilisés de manière interchangeable.

Quelle est la différence entre eux ?

Pourquoi voudriez-vous utiliser l'un plutôt que l'autre ?

Answer 1

JpaRepository étend PagingAndSortingRepository qui, à son tour, étend CrudRepository .

Leurs principales fonctions sont les suivantes :

• CrudRepository fournit principalement des fonctions CRUD.
• PagingAndSortingRepository fournit des méthodes pour effectuer la pagination et le tri des enregistrements.
• JpaRepository fournit certaines méthodes liées à JPA, telles que le vidage du contexte de persistance et la suppression d'enregistrements par lot.

En raison de l'héritage mentionné ci-dessus, JpaRepository aura toutes les fonctions de CrudRepository y PagingAndSortingRepository . Donc si vous n'avez pas besoin que le référentiel ait les fonctions fournies par JpaRepository y PagingAndSortingRepository utiliser CrudRepository .

Answer 2

La réponse de Ken est en principe correcte, mais j'aimerais intervenir sur la partie "pourquoi vouloir utiliser l'un plutôt que l'autre" de votre question.

Principes de base

L'interface de base que vous choisissez pour votre référentiel a deux objectifs principaux. Premièrement, vous permettez à l'infrastructure du référentiel Spring Data de trouver votre interface et de déclencher la création d'un proxy afin que vous puissiez injecter des instances de l'interface dans les clients. Le second objectif est d'intégrer autant de fonctionnalités que nécessaire dans l'interface sans avoir à déclarer des méthodes supplémentaires.

Les interfaces communes

La bibliothèque principale de Spring Data est livrée avec deux interfaces de base qui exposent un ensemble de fonctionnalités dédiées :

• CrudRepository - Méthodes CRUD
• PagingAndSortingRepository - des méthodes de pagination et de tri (étendues CrudRepository )

Interfaces spécifiques aux magasins

Les modules de stockage individuels (par exemple, pour JPA ou MongoDB) exposent des extensions spécifiques au stockage de ces interfaces de base afin de permettre l'accès à des fonctionnalités spécifiques au stockage, comme le flushing ou le batching dédié, qui prennent en compte certaines spécificités du stockage. Un exemple de ceci est deleteInBatch(…) de JpaRepository qui est différent de delete(…) car elle utilise une requête pour supprimer les entités données, ce qui est plus performant mais a pour effet secondaire de ne pas déclencher les cascades définies par JPA (comme la spécification le définit).

Nous recommandons généralement no d'utiliser ces interfaces de base car elles exposent la technologie de persistance sous-jacente aux clients et renforcent ainsi le couplage entre ces derniers et le référentiel. De plus, on s'éloigne un peu de la définition originale d'un référentiel qui est essentiellement "une collection d'entités". Donc, si vous le pouvez, restez avec PagingAndSortingRepository .

Interfaces de base de référentiel personnalisées

L'inconvénient de dépendre directement de l'une des interfaces de base fournies est double. Les deux peuvent être considérés comme théoriques, mais je pense qu'il est important d'en être conscient :

1. En fonction d'une interface de référentiel Spring Data, couplez votre interface de référentiel à la bibliothèque. Je ne pense pas que ce soit un problème particulier car vous utiliserez probablement des abstractions telles que Page o Pageable dans 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 fournit un avantage raisonnable, c'est parfait.
2. En étendant par exemple CrudRepository vous exposez un ensemble complet de méthodes de persistance en une seule fois. C'est probablement très bien dans la plupart des cas, mais vous pouvez rencontrer des situations où vous souhaitez obtenir un contrôle plus fin sur les méthodes exposées, par exemple pour créer un fichier ReadOnlyRepository qui n'inclut pas le save(…) y delete(…) méthodes de CrudRepository .

La solution à ces deux inconvénients consiste à créer votre propre interface de référentiel de base ou même un ensemble d'interfaces. Dans beaucoup d'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 dépôt est une interface de base générale qui ne corrige en fait que le point 1, mais qui lie également le type d'ID à être Long par souci de cohérence. La deuxième interface a généralement toutes les find…(…) méthodes copiées de CrudRepository y PagingAndSortingRepository mais n'expose pas les manipulateurs. Pour en savoir plus sur cette approche, consultez le documents de référence .

Résumé - tl;dr

L'abstraction du référentiel vous permet de choisir le référentiel de base en fonction de vos besoins architecturaux et fonctionnels. Utilisez ceux qui sont fournis dans la boîte s'ils conviennent, créez vos propres interfaces de base de référentiel si nécessaire. Restez à l'écart des interfaces de référentiel spécifiques au magasin, sauf si cela est inévitable.

Answer 3

Résumé :

• PagingAndSortingRepository extends CrudRepository

• JpaRepository extends PagingAndSortingRepository

El CrudRepository L'interface CRUD fournit des méthodes pour les opérations CRUD, ce qui vous permet de créer, lire, mettre à jour et supprimer des enregistrements sans avoir à définir vos propres méthodes.

El PagingAndSortingRepository fournit des méthodes supplémentaires pour récupérer les entités en utilisant la pagination et le tri.

Enfin, le JpaRepository ajouter quelques fonctionnalités supplémentaires spécifiques à JPA.

Answer 4

Je suis en train d'apprendre Spring Data JPA. Cela pourrait vous aider :

Answer 5

Voici les différences entre CrudRepository y JpaRepository comme :

CrudRepository

1. CrudRepository est une interface de base et étend l'interface Repository interface.
2. CrudRepository fournit principalement des opérations CRUD (Create, Read, Update, Delete).
3. Type de retour de saveAll() La méthode est Iterable .
4. Cas d'utilisation - Pour effectuer des opérations CRUD, définir l'extension du référentiel. CrudRepository .

JpaRepository

1. JpaRepository étend PagingAndSortingRepository qui s'étend CrudRepository .
2. JpaRepository fournit des opérations CRUD et de pagination, ainsi que des méthodes supplémentaires telles que flush() , saveAndFlush() y deleteInBatch() etc.
3. Type de retour de saveAll() est une méthode List .
4. Cas d'utilisation - Pour effectuer des opérations CRUD ainsi que des opérations par lots, définir le référentiel s'étend. JpaRepository .