Object-relational Mapping Using JPA, Hibernate and Spring Data JPA. Comparing the approaches of persisting entities

We're continuing our series on Object-relational Mapping Using JPA Hibernate and Spring Data JPA This time we look at comparing the approaches of persisting entities.

Comparing the approaches of persisting entities

We have followed the implementation of an application interacting with a database and that uses, alternatively, JPA, Hibernate native, and Spring Data JPA. Our purpose was to analyze each approach and how the needed configuration and the code to be written varies.

With JPA, we used its general API and needed a persistence provider. We may switch between persistence providers from the configuration.

We needed explicit management of the EntityManagerFactory, EntityManager, and transactions. The way the configuration is done and the amount of code to be written is similar to the Hibernate native approach. We may switch to the JPA approach by constructing an EntityManagerFactory from a Hibernate native configuration.

With Native Hibernate, we used the specific Hibernate native API. We built its configuration starting from the default Hibernate configuration files (hibernate.cfg.xml or hibernate.properties).

Object-relational Mapping Using JPA, Hibernate and Spring Data JPA Comparing the approaches of persisting entities.jpg


We needed explicit management of the SessionFactory, Session, and transactions. The way the configuration is done and the amount of code to be written is similar to the JPA approach. We may switch to the Hibernate native approach by unwrapping a SessionFactory from an EntityManagerFactory or a Session from an EntityManager.

With Spring Data JPA, we needed the additional Spring Data dependencies in the project. The configuration part also takes care of the creation of the beans needed for the project, including the transaction manager.

The repository interface needs only to be declared, and Spring Data will create an implementation for it as a proxy class with generated methods that interact with the database. We may use these methods directly, as they are generated by the framework, without taking care of defining them by ourselves.

The needed repository is injected and not explicitly created by the programmer. The amount of code to be written is the shortest from all these approaches, as the configuration part has taken most of the burden.

Looking back to the questions from the beginning of the article, we notice that Java frameworks address the problem of persisting information to the database in a more transparent way. Using Java frameworks, there is no more need to hand-code the CRUD (create, read, update, delete) operations in SQL and JDBC, this work is now managed by the ORM intermediary layer. ORM addresses portability, in the world of Relational Database Management Systems having proprietary dialects.

Interested in learning how to program with Java or in upgrading your Java programming skills? Check out our trainings

Catalin Tudose
Java and Web Technologies Expert

Share the knowledge

Still have questions?
Connect with us
Thank you.
Your request has been received.
Thank you!
The form has been submitted successfully.