Repositories

Базовый Spring
≈ 1 мин чтения

Репозиторий вместо повторяющегося EntityManager-кода

JPA уже умеет сохранять и загружать сущности через EntityManager. Но если в каждом сервисе вручную писать одинаковые методы поиска, сохранения и удаления, слой доступа к данным быстро заполнится шаблонным кодом. Spring Data JPA предлагает вынести такой контракт в интерфейс репозитория.

interface CustomerRepository extends Repository<Customer, Long> {
    Optional<Customer> findById(Long id);

    Customer save(Customer customer);
}

Здесь мы не пишем класс реализации. Spring Data анализирует интерфейс при запуске приложения и создаёт объект, который выполняет нужные операции через JPA. Первый generic-параметр указывает тип сущности, второй — тип её идентификатора.

Репозиторий остаётся частью модели приложения

То, что реализацию создаёт фреймворк, не означает, что интерфейс должен содержать все мыслимые запросы. Хороший репозиторий отражает операции, которые действительно нужны приложению, а бизнес-правила по-прежнему остаются в сервисах и других объектах предметной области.

Внутри Spring Data JPA всё равно работает с привычными JPA-механизмами. Сущности остаются сущностями, их состояние связано с persistence context, а выполнение запросов в итоге делегируется JPA provider.

Repository — это абстракция доступа к данным, а не новая ORM. Чтобы правильно понимать поведение сохранения, связей и загрузки, знания обычной JPA всё ещё необходимы.