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

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

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

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

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

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

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

Ответ Кена в основном прав, но я хотел бы услышать «почему вы хотите использовать один над другим?». часть вашего вопроса.

основы

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

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

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

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

Специфичные для магазина интерфейсы

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

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

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

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

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

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

 interface ApplicationRepository extends PagingAndSortingRepository { } interface ReadOnlyRepository extends Repository { // Al finder methods go here } 

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

Основная информация – tl; dr

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

введите описание изображения здесь

Резюме:

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

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

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

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

Наконец, JpaRepository добавляет еще несколько функциональных возможностей, характерных для JPA.

  • Весенние данные и исходный запрос с разбивкой на страницы
  • Spring Data JPA: пакетная вставка для вложенных объектов
  • Spring Data + JPA с несколькими источниками данных, но только один набор репозиториев
  • Как работает FetchMode в Spring Data JPA
  • setMaxResults для annotations Spring-Data-JPA?
  • Обработка мягких удалений с помощью Spring JPA
  • Spring-Data FETCH JOIN with Paging не работает
  • Можно ли использовать исходный SQL в Spring Repository
  • Данные Spring jpa- Определен бит bean с именем 'entityManagerFactory'; Инъекция автоуведомленных зависимостей не удалась
  • Данные Spring: поддерживается «delete by»?
  • POSTing ассоциация суб-ресурсов @OneToMany в Spring Data REST
  • Давайте будем гением компьютера.