В чем разница между интерфейсами CrudRepository и JpaRepository в Spring Data JPA?

в чем разница между CrudRepository и JpaRepository интерфейсы в Spring Data JPA?

когда я вижу примеры в Интернете,я вижу, что они используются взаимозаменяемо. В чем разница между ними? Почему вы хотите использовать одно над другим?

379
java jpa spring spring-data spring-data-jpa

3 ответов

JpaRepository выходит PagingAndSortingRepository, который, в свою очередь, расширяет CrudRepository.

их основные функции:

  • CrudRepository главным образом обеспечивает функции CRUD.
  • PagingAndSortingRepository предоставляет методы для разбиения на страницы и сортировки записей.
  • JpaRepository предоставляет некоторые связанные с JPA методы, такие как очистка контекста сохраняемости и удаление записей в пакете.

из-за упомянутого выше наследования,JpaRepository будет иметь все функции CrudRepository и PagingAndSortingRepository. Так что если вам не нужен репозиторий для функции JpaRepository и PagingAndSortingRepository используйте CrudRepository.

540

ответ Кена в основном прав, но я хотел бы вмешаться в "Почему вы хотите использовать один над другим?- это часть твоего вопроса.

основы

базовый интерфейс, который вы выбираете для своего репозитория, имеет две основные цели. Во-первых, вы позволяете инфраструктуре хранилища данных Spring найти ваш интерфейс и инициировать создание прокси-сервера, чтобы внедрить экземпляры интерфейса в клиенты. Вторая цель состоит в том, чтобы вытащить столько функциональности, сколько необходимо в интерфейс без необходимости объявлять дополнительные методы.

общие интерфейсы

библиотека Spring Data core поставляется с двумя базовыми интерфейсами, которые предоставляют выделенный набор функций:

  • CrudRepository - методы CRUD
  • PagingAndSortingRepository - методы разбиения на страницы и сортировки (extends CrudRepository)

магазин-специальные интерфейсы

индивидуальные модули магазина (например для JPA или MongoDB) предоставляет расширения хранилища этих базовых интерфейсов, чтобы обеспечить доступ к функциям хранилища, таким как промывка или специальная дозировка, которые учитывают некоторые особенности магазина. Примером этого является deleteInBatch(…) of JpaRepository отличается от delete(…) поскольку он использует запрос для удаления данных сущностей, который более эффективен, но имеет побочный эффект не запуска каскадов, определенных JPA (как определяет его спецификация).

как правило, мы рекомендуем не использовать эти базовые интерфейсы, поскольку они предоставляют базовую технологию сохраняемости клиентам и таким образом затягивают связь между ними и репозиторием. Кроме того, вы немного отходите от исходного определения репозитория, который в основном является "коллекцией сущностей". Поэтому, если можете, оставайтесь с PagingAndSortingRepository.

пользовательские базовые интерфейсы репозитория

оборотная сторона сразу в зависимости от одного из обеспеченных низкопробных интерфейсов двухкратна. Оба их можно рассматривать как теоретические, но я думаю, что их важно знать:

  1. в зависимости от интерфейса хранилища данных Spring связывает интерфейс хранилища с библиотекой. я не думаю, что это конкретная проблема, поскольку вы, вероятно, будете использовать абстракции, такие как Page или Pageable в коде в любом случае. Spring Data ничем не отличается от любой другой библиотеки общего назначения, такой как commons-lang или Guava. Покуда он обеспечивает разумное Бенефит, все в порядке.
  2. путем расширения, например CrudRepository, вы выставляете полный набор метода персистентности сразу. это, вероятно, хорошо в большинстве случаев, но вы можете столкнуться с ситуациями, когда вы хотели бы получить более мелкозернистый контроль над методами, например, создать ReadOnlyRepository это не включает save(…) и delete(…) способы CrudRepository.

решение обоих этих недостатков заключается в создании собственной базы интерфейс репозитория или даже их набор. Во многих приложениях, мы видели что-то вроде этого:

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

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

  // Al finder methods go here
}

первый интерфейс репозитория - это базовый интерфейс общего назначения, который фактически фиксирует только точку 1, но также связывает тип ID как Long для обеспечения согласованности. Второй интерфейс обычно имеет все find…(…) методы скопированы с CrudRepository и PagingAndSortingRepository но не разоблачает манипулирующих. Подробнее об этом подходе читайте в разделе ссылка документация.

резюме-tl; dr

абстракция репозитория позволяет выбрать базовый репозиторий, полностью управляемый архитектурными и функциональными потребностями. Используйте те, которые предоставляются из коробки, если они подходят, создайте свои собственные базовые интерфейсы репозитория, если это необходимо. Держитесь подальше от интерфейсов хранилища хранилища, если это не неизбежно.

287

enter image description here

резюме:

  • PagingAndSortingRepository расширяет CrudRepository

  • JpaRepository расширяет PagingAndSortingRepository

на CrudRepository интерфейс предоставляет методы для операций CRUD, поэтому он позволяет создавать, читать, обновлять и удалять записи без необходимости определять собственные методы.

в PagingAndSortingRepository предоставляет дополнительные методы для извлечения объектов с помощью разбиения на страницы и сортировки.

наконец-то JpaRepository добавьте еще несколько функций, специфичных для JPA.

22