Переход от JDBC к Spring Data
Spring Framework JDBC & ORM: На практике разработчики редко используют чистый JDBC в больших приложениях. Сначала появились утилиты Spring JDBC (JdbcTemplate) для облегчения работы с JDBC (обработка исключений, освобождение ресурсов, шаблонный код). Затем, с распространением JPA/Hibernate, большинство приложений перешло на ORM для уровня данных.
Spring Data JPA – высокоуровневый абстракционный фреймворк над JPA/Hibernate. Он автоматически генерирует реализацию репозиториев (DAO) на основе интерфейсов, описанных разработчиком. Позволяет выполнять CRUD и сложные запросы с минимальным количеством кода.
Repository интерфейсы: Разработчик описывает интерфейс, например interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByEmail(String email); }. Spring Data во время запуска создаст класс, реализующий этот интерфейс, со всеми базовыми методами (findAll, save, delete) и методом findByEmail с соответствующим JPQL запросом по имени метода.
Преимущества Spring Data:
Меньше шаблонного кода – не нужно писать реализации репозиториев вручную.
Быстрая разработка – за счет готовых методов (findAll(), findById() и т.п.) и возможности объявлять сложные методы именованием (findByNameAndStatus автоматически строит запрос).
Интеграция со Spring Boot – автоматическая настройка источника данных, транзакций (@Transactional), простое подключение через автоконфигурацию.
Когда нужен чистый JDBC? Иногда для особо сложных запросов или оптимизации может использоваться JDBC (через JdbcTemplate) или родные SQL-запросы даже в ORM. Spring Data JPA позволяет помечать методы @Query(nativeQuery=true) для выполнения нативного SQL. Но в большинстве случаев, для бизнес-логики работы с данными, Spring Data JPA достаточно.
Пояснение
Переход к Spring Data JPA исторически обусловлен стремлением упростить слой доступа к данным (DAO). Раньше в приложениях обычно была своя реализация паттерна DAO: писали интерфейс, потом класс, использующий EntityManager или Hibernate SessionFactory, внутри методы find/save etc. Это рутинный код, который повторяется из проекта в проект. Spring Data взял этот шаблон и сделал обобщенным: достаточно указать, какая сущность и тип ключа – и получите готовый DAO.
Как это выглядит в современном Spring Boot приложении:
Подключаем зависимость spring-boot-starter-data-jpa (она притянет Hibernate и Spring Data JPA).
Настраиваем подключение к базе (URL, user, password) в application.properties. Spring Boot сам создаст DataSource, подключит Hibernate, включит транзакционность.
Определяем сущности с аннотациями @Entity как обсуждали.
Создаем интерфейсы репозиториев, обычно наследуя JpaRepository<T, ID> или CrudRepository. Например:
@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
List<Product> findByCategoryName(String categoryName);
@Query("SELECT p FROM Product p WHERE p.price > :minPrice")
List<Product> findExpensive(@Param("minPrice") BigDecimal minPrice);
}
Здесь первый метод Spring Data проанализирует имя findByCategoryName и самостоятельно составит JPQL: SELECT p FROM Product p WHERE p.category.name = ?1. Второй метод – мы явно написали JPQL в аннотации @Query, и Spring Data просто выполнит его. Реализации этих методов нам писать не нужно.
Используем репозиторий в сервисах: просто инжектим private ProductRepository productRepo; и вызываем методы, например productRepo.findById(id) или productRepo.save(product). Spring автоматически откроет транзакцию вокруг таких вызовов (если включена @EnableTransactionManagement или в Spring Boot по умолчанию), поэтому методы репозитория выполняются в транзакциях.
Под капотом: Spring Data JPA при старте генерирует прокси-объекты репозиториев. Когда вы вызываете, например, productRepo.findById(5), этот вызов делегируется внутрь, где с помощью EntityManager выполняется em.find(Product.class, 5). Для метода, основанного на именовании (как findByCategoryName), Spring Data парсит название метода, строит Criteria или JPQL запрос и также выполняет через EntityManager. Все это сильно упрощает разработку, уменьшая вероятность ошибок (вы не забудете закрыть ResultSet, как в JDBC, или вызвать transaction.commit(), все делается автоматически в рамках шаблона).
Spring JDBC vs JPA: В некоторых случаях, когда приложение простое или ORM нецелесообразен (например, очень сложные заранее оптимизированные SQL запросы), можно использовать Spring JDBC (JdbcTemplate) – это облегченная оболочка над JDBC, которая управляет ресурсами и переводит исключения в RuntimeExceptions Spring DataAccessException. Но чаще даже для простых CRUD выбирают связку JPA + Spring Data, потому что код получается чище. Spring Data позволяет также работать с MongoDB, Cassandra и прочими нереляционными хранилищами через похожие репозитории (Spring Data MongoDB, etc.), но это уже выходит за рамки данной темы.
Итого: мы начали с низкоуровневого JDBC, прошли к более удобному ORM (JPA/Hibernate), и на самом верху абстракции – Spring Data, которое фактически скрывает от разработчика детали выполнения запросов. Понимание всех слоев остается важным: случается, что нужно оптимизировать запрос Hibernate или использовать специфические возможности БД. Однако, для 80-90% задач бизнес-приложений Spring Data JPA предоставляет эффективное и современное решение.
Переход от JDBC к Spring Data
Переход от JDBC к Spring Data
Spring Framework JDBC & ORM: На практике разработчики редко используют чистый JDBC в больших приложениях. Сначала появились утилиты Spring JDBC (JdbcTemplate) для облегчения работы с JDBC (обработка исключений, освобождение ресурсов, шаблонный код). Затем, с распространением JPA/Hibernate, большинство приложений перешло на ORM для уровня данных.
Spring Data JPA – высокоуровневый абстракционный фреймворк над JPA/Hibernate. Он автоматически генерирует реализацию репозиториев (DAO) на основе интерфейсов, описанных разработчиком. Позволяет выполнять CRUD и сложные запросы с минимальным количеством кода.
Repository интерфейсы: Разработчик описывает интерфейс, например interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByEmail(String email); }. Spring Data во время запуска создаст класс, реализующий этот интерфейс, со всеми базовыми методами (findAll, save, delete) и методом findByEmail с соответствующим JPQL запросом по имени метода.
Преимущества Spring Data:
Меньше шаблонного кода – не нужно писать реализации репозиториев вручную.
Быстрая разработка – за счет готовых методов (findAll(), findById() и т.п.) и возможности объявлять сложные методы именованием (findByNameAndStatus автоматически строит запрос).
Интеграция со Spring Boot – автоматическая настройка источника данных, транзакций (@Transactional), простое подключение через автоконфигурацию.
Когда нужен чистый JDBC? Иногда для особо сложных запросов или оптимизации может использоваться JDBC (через JdbcTemplate) или родные SQL-запросы даже в ORM. Spring Data JPA позволяет помечать методы @Query(nativeQuery=true) для выполнения нативного SQL. Но в большинстве случаев, для бизнес-логики работы с данными, Spring Data JPA достаточно.
Пояснение
Переход к Spring Data JPA исторически обусловлен стремлением упростить слой доступа к данным (DAO). Раньше в приложениях обычно была своя реализация паттерна DAO: писали интерфейс, потом класс, использующий EntityManager или Hibernate SessionFactory, внутри методы find/save etc. Это рутинный код, который повторяется из проекта в проект. Spring Data взял этот шаблон и сделал обобщенным: достаточно указать, какая сущность и тип ключа – и получите готовый DAO.
Как это выглядит в современном Spring Boot приложении:
Подключаем зависимость spring-boot-starter-data-jpa (она притянет Hibernate и Spring Data JPA).
Настраиваем подключение к базе (URL, user, password) в application.properties. Spring Boot сам создаст DataSource, подключит Hibernate, включит транзакционность.
Определяем сущности с аннотациями @Entity как обсуждали.
Создаем интерфейсы репозиториев, обычно наследуя JpaRepository<T, ID> или CrudRepository. Например:
@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
List<Product> findByCategoryName(String categoryName);
@Query("SELECT p FROM Product p WHERE p.price > :minPrice")
List<Product> findExpensive(@Param("minPrice") BigDecimal minPrice);
}
Здесь первый метод Spring Data проанализирует имя findByCategoryName и самостоятельно составит JPQL: SELECT p FROM Product p WHERE p.category.name = ?1. Второй метод – мы явно написали JPQL в аннотации @Query, и Spring Data просто выполнит его. Реализации этих методов нам писать не нужно.
Используем репозиторий в сервисах: просто инжектим private ProductRepository productRepo; и вызываем методы, например productRepo.findById(id) или productRepo.save(product). Spring автоматически откроет транзакцию вокруг таких вызовов (если включена @EnableTransactionManagement или в Spring Boot по умолчанию), поэтому методы репозитория выполняются в транзакциях.
Под капотом: Spring Data JPA при старте генерирует прокси-объекты репозиториев. Когда вы вызываете, например, productRepo.findById(5), этот вызов делегируется внутрь, где с помощью EntityManager выполняется em.find(Product.class, 5). Для метода, основанного на именовании (как findByCategoryName), Spring Data парсит название метода, строит Criteria или JPQL запрос и также выполняет через EntityManager. Все это сильно упрощает разработку, уменьшая вероятность ошибок (вы не забудете закрыть ResultSet, как в JDBC, или вызвать transaction.commit(), все делается автоматически в рамках шаблона).
Spring JDBC vs JPA: В некоторых случаях, когда приложение простое или ORM нецелесообразен (например, очень сложные заранее оптимизированные SQL запросы), можно использовать Spring JDBC (JdbcTemplate) – это облегченная оболочка над JDBC, которая управляет ресурсами и переводит исключения в RuntimeExceptions Spring DataAccessException. Но чаще даже для простых CRUD выбирают связку JPA + Spring Data, потому что код получается чище. Spring Data позволяет также работать с MongoDB, Cassandra и прочими нереляционными хранилищами через похожие репозитории (Spring Data MongoDB, etc.), но это уже выходит за рамки данной темы.
Итого: мы начали с низкоуровневого JDBC, прошли к более удобному ORM (JPA/Hibernate), и на самом верху абстракции – Spring Data, которое фактически скрывает от разработчика детали выполнения запросов. Понимание всех слоев остается важным: случается, что нужно оптимизировать запрос Hibernate или использовать специфические возможности БД. Однако, для 80-90% задач бизнес-приложений Spring Data JPA предоставляет эффективное и современное решение.
Spring Framework JDBC & ORM: На практике разработчики редко используют чистый JDBC в больших приложениях. Сначала появились утилиты Spring JDBC (JdbcTemplate) для облегчения работы с JDBC (обработка исключений, освобождение ресурсов, шаблонный код). Затем, с распространением JPA/Hibernate, большинство приложений перешло на ORM для уровня данных.
Spring Data JPA – высокоуровневый абстракционный фреймворк над JPA/Hibernate. Он автоматически генерирует реализацию репозиториев (DAO) на основе интерфейсов, описанных разработчиком. Позволяет выполнять CRUD и сложные запросы с минимальным количеством кода.
Repository интерфейсы: Разработчик описывает интерфейс, например interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByEmail(String email); }. Spring Data во время запуска создаст класс, реализующий этот интерфейс, со всеми базовыми методами (findAll, save, delete) и методом findByEmail с соответствующим JPQL запросом по имени метода.
Преимущества Spring Data:
Меньше шаблонного кода – не нужно писать реализации репозиториев вручную.
Быстрая разработка – за счет готовых методов (findAll(), findById() и т.п.) и возможности объявлять сложные методы именованием (findByNameAndStatus автоматически строит запрос).
Интеграция со Spring Boot – автоматическая настройка источника данных, транзакций (@Transactional), простое подключение через автоконфигурацию.
Когда нужен чистый JDBC? Иногда для особо сложных запросов или оптимизации может использоваться JDBC (через JdbcTemplate) или родные SQL-запросы даже в ORM. Spring Data JPA позволяет помечать методы @Query(nativeQuery=true) для выполнения нативного SQL. Но в большинстве случаев, для бизнес-логики работы с данными, Spring Data JPA достаточно.
Пояснение
Переход к Spring Data JPA исторически обусловлен стремлением упростить слой доступа к данным (DAO). Раньше в приложениях обычно была своя реализация паттерна DAO: писали интерфейс, потом класс, использующий EntityManager или Hibernate SessionFactory, внутри методы find/save etc. Это рутинный код, который повторяется из проекта в проект. Spring Data взял этот шаблон и сделал обобщенным: достаточно указать, какая сущность и тип ключа – и получите готовый DAO.
Как это выглядит в современном Spring Boot приложении:
Подключаем зависимость spring-boot-starter-data-jpa (она притянет Hibernate и Spring Data JPA).
Настраиваем подключение к базе (URL, user, password) в application.properties. Spring Boot сам создаст DataSource, подключит Hibernate, включит транзакционность.
Определяем сущности с аннотациями @Entity как обсуждали.
Создаем интерфейсы репозиториев, обычно наследуя JpaRepository<T, ID> или CrudRepository. Например:
@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
List<Product> findByCategoryName(String categoryName);
@Query("SELECT p FROM Product p WHERE p.price > :minPrice")
List<Product> findExpensive(@Param("minPrice") BigDecimal minPrice);
}
Здесь первый метод Spring Data проанализирует имя findByCategoryName и самостоятельно составит JPQL: SELECT p FROM Product p WHERE p.category.name = ?1. Второй метод – мы явно написали JPQL в аннотации @Query, и Spring Data просто выполнит его. Реализации этих методов нам писать не нужно.
Используем репозиторий в сервисах: просто инжектим private ProductRepository productRepo; и вызываем методы, например productRepo.findById(id) или productRepo.save(product). Spring автоматически откроет транзакцию вокруг таких вызовов (если включена @EnableTransactionManagement или в Spring Boot по умолчанию), поэтому методы репозитория выполняются в транзакциях.
Под капотом: Spring Data JPA при старте генерирует прокси-объекты репозиториев. Когда вы вызываете, например, productRepo.findById(5), этот вызов делегируется внутрь, где с помощью EntityManager выполняется em.find(Product.class, 5). Для метода, основанного на именовании (как findByCategoryName), Spring Data парсит название метода, строит Criteria или JPQL запрос и также выполняет через EntityManager. Все это сильно упрощает разработку, уменьшая вероятность ошибок (вы не забудете закрыть ResultSet, как в JDBC, или вызвать transaction.commit(), все делается автоматически в рамках шаблона).
Spring JDBC vs JPA: В некоторых случаях, когда приложение простое или ORM нецелесообразен (например, очень сложные заранее оптимизированные SQL запросы), можно использовать Spring JDBC (JdbcTemplate) – это облегченная оболочка над JDBC, которая управляет ресурсами и переводит исключения в RuntimeExceptions Spring DataAccessException. Но чаще даже для простых CRUD выбирают связку JPA + Spring Data, потому что код получается чище. Spring Data позволяет также работать с MongoDB, Cassandra и прочими нереляционными хранилищами через похожие репозитории (Spring Data MongoDB, etc.), но это уже выходит за рамки данной темы.
Итого: мы начали с низкоуровневого JDBC, прошли к более удобному ORM (JPA/Hibernate), и на самом верху абстракции – Spring Data, которое фактически скрывает от разработчика детали выполнения запросов. Понимание всех слоев остается важным: случается, что нужно оптимизировать запрос Hibernate или использовать специфические возможности БД. Однако, для 80-90% задач бизнес-приложений Spring Data JPA предоставляет эффективное и современное решение.
Автор: к.п.н., Румянцев Сергей Александрович, доцент Финансового университета при Правительстве РФ; доцент ОЧУВО Международного инновационного университета; Консалтинг, управление разработкой ПО; системный и бизнес анализ; менеджмент; аналитиз данных; управление ИТ. Телефон для связи +79269444818 (мессенджеры)
Короткая ссылка:
Переход от JDBC к Spring Data
Spring Framework JDBC & ORM: На практике разработчики редко используют чистый JDBC в больших приложениях. Сначала появились утилиты Spring JDBC (JdbcTemplate) для облегчения работы с JDBC (обработка исключений, освобождение ресурсов, шаблонный код). Затем, с распространением JPA/Hibernate, большинство приложений перешло на ORM для уровня данных.
Spring Data JPA – высокоуровневый абстракционный фреймворк над JPA/Hibernate. Он автоматически генерирует реализацию репозиториев (DAO) на основе интерфейсов, описанных разработчиком. Позволяет выполнять CRUD и сложные запросы с минимальным количеством кода.
Repository интерфейсы: Разработчик описывает интерфейс, например interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByEmail(String email); }. Spring Data во время запуска создаст класс, реализующий этот интерфейс, со всеми базовыми методами (findAll, save, delete) и методом findByEmail с соответствующим JPQL запросом по имени метода.
Преимущества Spring Data:
Меньше шаблонного кода – не нужно писать реализации репозиториев вручную.
Быстрая разработка – за счет готовых методов (findAll(), findById() и т.п.) и возможности объявлять сложные методы именованием (findByNameAndStatus автоматически строит запрос).
Интеграция со Spring Boot – автоматическая настройка источника данных, транзакций (@Transactional), простое подключение через автоконфигурацию.
Когда нужен чистый JDBC? Иногда для особо сложных запросов или оптимизации может использоваться JDBC (через JdbcTemplate) или родные SQL-запросы даже в ORM. Spring Data JPA позволяет помечать методы @Query(nativeQuery=true) для выполнения нативного SQL. Но в большинстве случаев, для бизнес-логики работы с данными, Spring Data JPA достаточно.
Пояснение
Переход к Spring Data JPA исторически обусловлен стремлением упростить слой доступа к данным (DAO). Раньше в приложениях обычно была своя реализация паттерна DAO: писали интерфейс, потом класс, использующий EntityManager или Hibernate SessionFactory, внутри методы find/save etc. Это рутинный код, который повторяется из проекта в проект. Spring Data взял этот шаблон и сделал обобщенным: достаточно указать, какая сущность и тип ключа – и получите готовый DAO.
Как это выглядит в современном Spring Boot приложении:
Подключаем зависимость spring-boot-starter-data-jpa (она притянет Hibernate и Spring Data JPA).
Настраиваем подключение к базе (URL, user, password) в application.properties. Spring Boot сам создаст DataSource, подключит Hibernate, включит транзакционность.
Определяем сущности с аннотациями @Entity как обсуждали.
Создаем интерфейсы репозиториев, обычно наследуя JpaRepository<T, ID> или CrudRepository. Например:
@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
List<Product> findByCategoryName(String categoryName);
@Query("SELECT p FROM Product p WHERE p.price > :minPrice")
List<Product> findExpensive(@Param("minPrice") BigDecimal minPrice);
}
Здесь первый метод Spring Data проанализирует имя findByCategoryName и самостоятельно составит JPQL: SELECT p FROM Product p WHERE p.category.name = ?1. Второй метод – мы явно написали JPQL в аннотации @Query, и Spring Data просто выполнит его. Реализации этих методов нам писать не нужно.
Используем репозиторий в сервисах: просто инжектим private ProductRepository productRepo; и вызываем методы, например productRepo.findById(id) или productRepo.save(product). Spring автоматически откроет транзакцию вокруг таких вызовов (если включена @EnableTransactionManagement или в Spring Boot по умолчанию), поэтому методы репозитория выполняются в транзакциях.
Под капотом: Spring Data JPA при старте генерирует прокси-объекты репозиториев. Когда вы вызываете, например, productRepo.findById(5), этот вызов делегируется внутрь, где с помощью EntityManager выполняется em.find(Product.class, 5). Для метода, основанного на именовании (как findByCategoryName), Spring Data парсит название метода, строит Criteria или JPQL запрос и также выполняет через EntityManager. Все это сильно упрощает разработку, уменьшая вероятность ошибок (вы не забудете закрыть ResultSet, как в JDBC, или вызвать transaction.commit(), все делается автоматически в рамках шаблона).
Spring JDBC vs JPA: В некоторых случаях, когда приложение простое или ORM нецелесообразен (например, очень сложные заранее оптимизированные SQL запросы), можно использовать Spring JDBC (JdbcTemplate) – это облегченная оболочка над JDBC, которая управляет ресурсами и переводит исключения в RuntimeExceptions Spring DataAccessException. Но чаще даже для простых CRUD выбирают связку JPA + Spring Data, потому что код получается чище. Spring Data позволяет также работать с MongoDB, Cassandra и прочими нереляционными хранилищами через похожие репозитории (Spring Data MongoDB, etc.), но это уже выходит за рамки данной темы.
Итого: мы начали с низкоуровневого JDBC, прошли к более удобному ORM (JPA/Hibernate), и на самом верху абстракции – Spring Data, которое фактически скрывает от разработчика детали выполнения запросов. Понимание всех слоев остается важным: случается, что нужно оптимизировать запрос Hibernate или использовать специфические возможности БД. Однако, для 80-90% задач бизнес-приложений Spring Data JPA предоставляет эффективное и современное решение.
https://webprogr.ru/~eT1KV
Spring Framework JDBC & ORM: На практике разработчики редко используют чистый JDBC в больших приложениях. Сначала появились утилиты Spring JDBC (JdbcTemplate) для облегчения работы с JDBC (обработка исключений, освобождение ресурсов, шаблонный код). Затем, с распространением JPA/Hibernate, большинство приложений перешло на ORM для уровня данных.
Spring Data JPA – высокоуровневый абстракционный фреймворк над JPA/Hibernate. Он автоматически генерирует реализацию репозиториев (DAO) на основе интерфейсов, описанных разработчиком. Позволяет выполнять CRUD и сложные запросы с минимальным количеством кода.
Repository интерфейсы: Разработчик описывает интерфейс, например interface UserRepository extends JpaRepository<User, Long> { Optional<User> findByEmail(String email); }. Spring Data во время запуска создаст класс, реализующий этот интерфейс, со всеми базовыми методами (findAll, save, delete) и методом findByEmail с соответствующим JPQL запросом по имени метода.
Преимущества Spring Data:
Меньше шаблонного кода – не нужно писать реализации репозиториев вручную.
Быстрая разработка – за счет готовых методов (findAll(), findById() и т.п.) и возможности объявлять сложные методы именованием (findByNameAndStatus автоматически строит запрос).
Интеграция со Spring Boot – автоматическая настройка источника данных, транзакций (@Transactional), простое подключение через автоконфигурацию.
Когда нужен чистый JDBC? Иногда для особо сложных запросов или оптимизации может использоваться JDBC (через JdbcTemplate) или родные SQL-запросы даже в ORM. Spring Data JPA позволяет помечать методы @Query(nativeQuery=true) для выполнения нативного SQL. Но в большинстве случаев, для бизнес-логики работы с данными, Spring Data JPA достаточно.
Пояснение
Переход к Spring Data JPA исторически обусловлен стремлением упростить слой доступа к данным (DAO). Раньше в приложениях обычно была своя реализация паттерна DAO: писали интерфейс, потом класс, использующий EntityManager или Hibernate SessionFactory, внутри методы find/save etc. Это рутинный код, который повторяется из проекта в проект. Spring Data взял этот шаблон и сделал обобщенным: достаточно указать, какая сущность и тип ключа – и получите готовый DAO.
Как это выглядит в современном Spring Boot приложении:
Подключаем зависимость spring-boot-starter-data-jpa (она притянет Hibernate и Spring Data JPA).
Настраиваем подключение к базе (URL, user, password) в application.properties. Spring Boot сам создаст DataSource, подключит Hibernate, включит транзакционность.
Определяем сущности с аннотациями @Entity как обсуждали.
Создаем интерфейсы репозиториев, обычно наследуя JpaRepository<T, ID> или CrudRepository. Например:
@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
List<Product> findByCategoryName(String categoryName);
@Query("SELECT p FROM Product p WHERE p.price > :minPrice")
List<Product> findExpensive(@Param("minPrice") BigDecimal minPrice);
}
Здесь первый метод Spring Data проанализирует имя findByCategoryName и самостоятельно составит JPQL: SELECT p FROM Product p WHERE p.category.name = ?1. Второй метод – мы явно написали JPQL в аннотации @Query, и Spring Data просто выполнит его. Реализации этих методов нам писать не нужно.
Используем репозиторий в сервисах: просто инжектим private ProductRepository productRepo; и вызываем методы, например productRepo.findById(id) или productRepo.save(product). Spring автоматически откроет транзакцию вокруг таких вызовов (если включена @EnableTransactionManagement или в Spring Boot по умолчанию), поэтому методы репозитория выполняются в транзакциях.
Под капотом: Spring Data JPA при старте генерирует прокси-объекты репозиториев. Когда вы вызываете, например, productRepo.findById(5), этот вызов делегируется внутрь, где с помощью EntityManager выполняется em.find(Product.class, 5). Для метода, основанного на именовании (как findByCategoryName), Spring Data парсит название метода, строит Criteria или JPQL запрос и также выполняет через EntityManager. Все это сильно упрощает разработку, уменьшая вероятность ошибок (вы не забудете закрыть ResultSet, как в JDBC, или вызвать transaction.commit(), все делается автоматически в рамках шаблона).
Spring JDBC vs JPA: В некоторых случаях, когда приложение простое или ORM нецелесообразен (например, очень сложные заранее оптимизированные SQL запросы), можно использовать Spring JDBC (JdbcTemplate) – это облегченная оболочка над JDBC, которая управляет ресурсами и переводит исключения в RuntimeExceptions Spring DataAccessException. Но чаще даже для простых CRUD выбирают связку JPA + Spring Data, потому что код получается чище. Spring Data позволяет также работать с MongoDB, Cassandra и прочими нереляционными хранилищами через похожие репозитории (Spring Data MongoDB, etc.), но это уже выходит за рамки данной темы.
Итого: мы начали с низкоуровневого JDBC, прошли к более удобному ORM (JPA/Hibernate), и на самом верху абстракции – Spring Data, которое фактически скрывает от разработчика детали выполнения запросов. Понимание всех слоев остается важным: случается, что нужно оптимизировать запрос Hibernate или использовать специфические возможности БД. Однако, для 80-90% задач бизнес-приложений Spring Data JPA предоставляет эффективное и современное решение.
Короткая ссылка на новость:https://webprogr.ru/~eT1KV
Последние новости