¿Cuál es la diferencia entre las interfaces CrudRepository y JpaRepository en Spring Data JPA ?
Cuando veo los ejemplos en la web, veo que se usan de manera intercambiable.
¿Cuál es la diferencia entre ellos?
¿Por qué querrías usar uno sobre el otro?
java
spring
jpa
spring-data
spring-data-jpa
kseeker
fuente
fuente
Respuestas:
JpaRepository
se extiendePagingAndSortingRepository
que a su vez se extiendeCrudRepository
.Sus funciones principales son:
CrudRepository
proporciona principalmente funciones CRUD.PagingAndSortingRepository
proporciona métodos para hacer paginación y ordenar registros.JpaRepository
proporciona algunos métodos relacionados con JPA, como vaciar el contexto de persistencia y eliminar registros en un lote.Debido a la herencia mencionada anteriormente,
JpaRepository
tendrá todas las funciones deCrudRepository
yPagingAndSortingRepository
. Entonces, si no necesita el repositorio para tener las funciones proporcionadas porJpaRepository
yPagingAndSortingRepository
, useCrudRepository
.fuente
La respuesta de Ken es básicamente correcta, pero me gustaría intervenir en el "¿por qué quieres usar uno sobre el otro?" parte de tu pregunta
Lo esencial
La interfaz base que elija para su repositorio tiene dos propósitos principales. Primero, permite que la infraestructura del repositorio de Spring Data encuentre su interfaz y active la creación de proxy para inyectar instancias de la interfaz en los clientes. El segundo propósito es incorporar tanta funcionalidad como sea necesaria a la interfaz sin tener que declarar métodos adicionales.
Las interfaces comunes
La biblioteca central de Spring Data se entrega con dos interfaces base que exponen un conjunto dedicado de funcionalidades:
CrudRepository
- métodos CRUDPagingAndSortingRepository
- métodos para paginación y clasificación (se extiendeCrudRepository
)Interfaces específicas de la tienda
Los módulos de la tienda individual (por ejemplo, para JPA o MongoDB) exponen extensiones específicas de la tienda de estas interfaces básicas para permitir el acceso a la funcionalidad específica de la tienda, como el vaciado o el procesamiento por lotes dedicado que tiene en cuenta algunos detalles de la tienda. Un ejemplo de esto es
deleteInBatch(…)
deJpaRepository
que es diferente dedelete(…)
, ya que utiliza una consulta para eliminar las entidades dado que es más performant pero viene con el efecto secundario de no activación de las cascadas de la APP definidas (como los define spec IT).En general, recomendamos no utilizar estas interfaces base, ya que exponen la tecnología de persistencia subyacente a los clientes y, por lo tanto, ajustan el acoplamiento entre ellos y el repositorio. Además, te alejas un poco de la definición original de un repositorio que es básicamente "una colección de entidades". Así que si puedes, quédate con
PagingAndSortingRepository
.Interfaces base de repositorio personalizado
La desventaja de depender directamente de una de las interfaces base proporcionadas es doble. Ambos pueden considerarse teóricos, pero creo que es importante tenerlos en cuenta:
Page
oPageable
en tu código de todos modos. Spring Data no es diferente de ninguna otra biblioteca de uso general como commons-lang o Guava. Siempre que proporcione un beneficio razonable, está bien.CrudRepository
, por ejemplo , expone un conjunto completo de método de persistencia a la vez. Probablemente esto también esté bien en la mayoría de las circunstancias, pero es posible que se encuentre con situaciones en las que le gustaría obtener un control más detallado sobre la exposición de los métodos, por ejemplo, para crear unaReadOnlyRepository
que no incluya los métodossave(…)
y .delete(…)
CrudRepository
La solución a estos dos inconvenientes es crear su propia interfaz de repositorio base o incluso un conjunto de ellos. En muchas aplicaciones he visto algo como esto:
La primera interfaz del repositorio es una interfaz básica de propósito general que en realidad solo corrige el punto 1 pero también vincula el tipo de ID para que sea
Long
coherente. La segunda interfaz generalmente tiene todos losfind…(…)
métodos copiadosCrudRepository
yPagingAndSortingRepository
no expone los manipuladores. Lea más sobre ese enfoque en la documentación de referencia .Resumen - tl; dr
La abstracción del repositorio le permite elegir el repositorio base totalmente impulsado por sus necesidades arquitectónicas y funcionales. Utilice los que se proporcionan de fábrica si son adecuados, elabore sus propias interfaces base de repositorio si es necesario. Manténgase alejado de las interfaces de repositorio específicas de la tienda a menos que sea inevitable.
fuente
Resumen:
PagingAndSortingRepository extiende CrudRepository
JpaRepository extiende PagingAndSortingRepository
La interfaz CrudRepository proporciona métodos para operaciones CRUD, por lo que le permite crear, leer, actualizar y eliminar registros sin tener que definir sus propios métodos.
El PagingAndSortingRepository proporciona métodos adicionales para recuperar las entidades que utilizan la paginación y la clasificación.
Finalmente, JpaRepository agrega algunas funcionalidades más que son específicas de JPA.
fuente
Estoy aprendiendo Spring Data JPA. Te puede ayudar:
fuente
Todas las respuestas proporcionan detalles suficientes para la pregunta. Sin embargo, déjame agregar algo más.
¿Por qué estamos usando estas interfaces?
Qué interfaz hace qué:
Cuándo usar qué interfaz:
De acuerdo con http://jtuts.com/2014/08/26/difference-between-crudrepository-and-jparepository-in-spring-data-jpa/
En general, la mejor idea es usar CrudRepository o PagingAndSortingRepository dependiendo de si necesita ordenar y paginar o no.
El JpaRepository debe evitarse si es posible, ya que vincula sus repositorios con la tecnología de persistencia JPA, y en la mayoría de los casos probablemente ni siquiera usaría los métodos adicionales proporcionados por él.
fuente