java - metodos - pagingandsortingrepository

¿Cuál es la diferencia entre las interfaces CrudRepository y JpaRepository en Spring Data JPA?

Question

¿Cuál es la diferencia entre las interfaces CrudRepository y JpaRepository en Spring Data JPA?

Cuando veo los ejemplos en la web, los veo usados ​​indistintamente. ¿Cuál es la diferencia entre ellos? ¿Por qué querrías usar uno sobre el otro?

Answer 1

La respuesta de Ken es básicamente correcta, pero me gustaría repasar el "¿por qué querrías 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 del proxy para que pueda inyectar instancias de la interfaz en los clientes. El segundo propósito es incorporar tanta funcionalidad como sea necesario en la interfaz sin tener que declarar métodos adicionales.

Las interfaces comunes

La biblioteca principal de Spring Data se entrega con dos interfaces base que exponen un conjunto dedicado de funcionalidades:

• CrudRepository - métodos de CRUD
• PagingAndSortingRepository : métodos para la paginación y clasificación (amplía CrudRepository )

Interfaces específicas de la tienda

Los módulos de tienda individuales (por ejemplo, para JPA o MongoDB) exponen extensiones específicas de la tienda de estas interfaces base para permitir el acceso a la funcionalidad específica de la tienda, como el vaciado o el procesamiento por lotes dedicado, que tienen en cuenta algunas características específicas de la tienda. Un ejemplo de esto es deleteInBatch(…) de JpaRepository que es diferente de delete(…) ya que utiliza una consulta para eliminar las entidades dadas, que es más eficaz pero tiene el efecto secundario de no activar las cascadas definidas por la JPA (como La especificación lo define).

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, se aleja 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 personalizadas

La desventaja de que depende directamente de una de las interfaces base provistas es doble. Ambos pueden considerarse teóricos, pero creo que es importante tenerlos en cuenta:

1. Dependiendo de la interfaz del repositorio de Spring Data, se acopla la interfaz del repositorio a la biblioteca. No creo que este sea un problema en particular, ya que de todos modos probablemente Pageable abstracciones como Page o Pageable en tu código. Spring Data no es diferente de ninguna otra biblioteca de propósito general como commons-lang o Guava. Siempre y cuando proporcione un beneficio razonable, está bien.
2. Al extender, por ejemplo, CrudRepository , expone un conjunto completo de métodos de persistencia a la vez. Es probable que esto también esté bien en la mayoría de las circunstancias, pero podría encontrarse en situaciones en las que le gustaría obtener un control más preciso sobre los métodos expuestos, por ejemplo, para crear un ReadOnlyRepository que no incluya save(…) y delete(…) Métodos de 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:

interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }

interface ReadOnlyRepository<T> extends Repository<T, Long> {

  // Al finder methods go here
}

La primera interfaz de repositorio es una interfaz de base de propósito general que en realidad solo corrige el punto 1, pero también vincula el tipo de ID para que sea Long y consistente. La segunda interfaz generalmente tiene todos los métodos de find…(…) copiados de CrudRepository y PagingAndSortingRepository pero 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 forma inmediata si son adecuados, cree sus propias interfaces de base de repositorio si es necesario. Manténgase alejado de las interfaces de repositorio específicas de la tienda a menos que sea inevitable.

Answer 2

JpaRepository extiende PagingAndSortingRepository que a su vez extiende CrudRepository .

Sus principales funciones son:

• CrudRepository proporciona principalmente funciones de CRUD.
• PagingAndSortingRepository proporciona métodos para realizar la paginación y ordenar los 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 de CrudRepository y PagingAndSortingRepository . Entonces, si no necesita el repositorio para tener las funciones proporcionadas por JpaRepository y PagingAndSortingRepository , use CrudRepository .

Answer 3

Resumen:

• PagingAndSortingRepository extiende CrudRepository

• JpaRepository extiende PagingAndSortingRepository

La interfaz CrudRepository proporciona métodos para las operaciones de 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 entidades mediante la paginación y la clasificación.

Finalmente, JpaRepository agrega algunas funciones más que son específicas de JPA.