Hibernate is not so evil

A few years ago, when I was a Junior Backend Developer, I was really frustrated at Hibernate. Every time I made any change in the persistence layer designed by my older colleagues, I had serious problems with JPA. I thought that maybe Hibernate was some kind of an old crappy tool nobody wants to use anymore. Especially, when I saw the alternatives — lightweight, small ORM frameworks like <a href="https://github.com/JetBrains/Exposed" rel="noopener ugc nofollow" target="_blank">Exposed</a>. However, after many years of using JPA, I started to see the bigger picture. After many unequal fights with Hibernate, I started to know it better. I started to understand why it does what it does. Today I know that there is an <a href="https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch" rel="noopener ugc nofollow" target="_blank">object-relational impedance mismatch</a>, which cannot be avoided when using ORM and it’s totally irrational to be upset about it. I wrote about it in my last article: <a href="https://medium.com/kotlin-academy/kotlin-and-jpa-a-good-match-or-a-recipe-for-failure-e52718d93b4f" rel="noopener">“Kotlin and JPA — a good match or a recipe for failure?”</a>, in which I focus mainly on cooperation between Kotlin and Hibernate, but you can also read their ORMs in general and about different perspectives on the persistence issue. So if you don’t know what exactly the object-relational impedance mismatch is, feel free to read it. <h1>Definitions</h1> Let’s start by defining stuff. People tend to use the following terms: JPA, Hibernate, and Spring Data JPA interchangeably like these were just different names for the same thing. But they are not! JPA (Java Persistence API) is an interface specification that describes how to manage relational data in Java applications. So it’s basically just a set of rules to follow. In <a href="https://download.oracle.com/otn-pub/jcp/persistence-2_1-fr-eval-spec/JavaPersistence.pdf" rel="noopener ugc nofollow" target="_blank">the specification document</a>, you can read e.g. what the constraints for an entity class are, i.e. which rules an entity class has to satisfy to be managed properly by any JPA provider. So if there is an interface (JPA), there must be an implementation, right? This is basically what Hibernate is — an implementation of JPA. The most popular one. The most powerful one. And probably the most hated one. Both Hibernate and JPA expose methods for managing relational data in Java applications, but usually, we don’t operate on that level of abstraction. During the business logic implementation, we shouldn’t need to use EntityManager or HibernateSession directly, because they are just implementation details and the actual domain doesn’t need to know how exactly we’re going to persist the data. So we need to put some abstraction on top of Hibernate/JPA. That’s why the Repository design pattern — introduced at the tactical level of Domain Driven Design — is so commonly used and that’s also probably the reason why Spring Data JPA is so popular. It introduces another layer of abstraction, which makes the JPA so convenient and easy to use. Moreover, you don’t need to pick Hibernate when using Spring Data JPA. You might want to use another provider, e.g. EclipseLink. Using Spring Data JPA let us avoid a lot of boilerplate code because most of the common usages of JPA are already provided in the implementation of such interfaces as <code>org.springframework.data.jpa.repository.JpaRepository</code>, which is a part of the Spring Data JPA. <a href="https://betterprogramming.pub/hibernate-is-not-so-evil-84ca72b959c3">Read More</a>