¿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?
Respuestas:
JpaRepositoryse extiende PagingAndSortingRepositoryque a su vez se extiende CrudRepository.
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, JpaRepositorytendrá todas las funciones de CrudRepositoryy PagingAndSortingRepository. Entonces, si no necesita el repositorio para tener las funciones proporcionadas por JpaRepositoryy PagingAndSortingRepository, use CrudRepository.
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
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.
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 extiende CrudRepository)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(…)de JpaRepositoryque es diferente de delete(…), 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.
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:
Pageo Pageableen 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 una ReadOnlyRepositoryque no incluya los métodos save(…)y .delete(…)CrudRepositoryLa 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:
interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }
interface ReadOnlyRepository<T> extends Repository<T, Long> {
// Al finder methods go here
}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 Longcoherente. La segunda interfaz generalmente tiene todos los find…(…)métodos copiados CrudRepositoryy PagingAndSortingRepositoryno expone los manipuladores. Lea más sobre ese enfoque en la documentación de referencia .
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.
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.
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.
