Сравнение подходов к постоянному хранению сущностей

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

В случае JPA, мы использовали общий интерфейс, и нам потребовался провайдер персистентности. Мы можем переключаться между различными провайдерами из конфигурации.

Нам потребовалось прямое управление EntityManagerFactory, EntityManager и транзакциями. Способ создания конфигурации и объем необходимого кода примерно такие же, как при использовании подхода Hibernate native. Мы можем переключиться на подход JPA, создав EntityManagerFactory из конфигурации Hibernate native.

В случае Native Hibernate мы использовали специальный интерфейс Hibernate native API. Мы построили его конфигурацию из стандартных файлов конфигурации (hibernate.cfg.xml или hibernate.properties).

Нам потребовалось прямое управление essionFactory, Session и транзакциями. Способ создания конфигурации и объем необходимого кода примерно такие же, как при использовании подхода JPA. Мы можем переключиться на подход Hibernate native, развернув SessionFactory из EntityManagerFactory или Session из EntityManager.

В случае Spring Data JPA, нам потребовались дополнительные зависимости Spring Data в проекте. Конфигурация обеспечивает создание бинов, необходимых для проекта, в том числе диспетчер транзакций.

Необходимо только декларировать интерфейс репозитория, и Spring Data создаст реализацию для его класса proxy с генерированными методами, которые взаимодействую с базой данных. Мы можем использовать эти методы напрямую, когда они генерируются фреймворком, и нет необходимость самостоятельно определять их.

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

Возвращаясь к вопросам из начала это статьи, можно отметить, что фреймворки Java более прозрачным образом решают проблему постоянного сохранения информации в базе данных. При использовании фреймворков Java нет необходимости писать код для операций CRUD (create, read, update, delete) на SQL и JDBC. Теперь эта задача выполняется промежуточным уровнем ORM. ORM решает проблему переносимости в сфере систем управления реляционными базами данных, имеющих собственные диалекты языка.