Hibernate and JPA, what to use, where?

Can someone please explain to me what are the main differences between JPA and Hibernate?

Where to use Hibernate?

Where to use JPA?

Why not bean essence?

+7
java orm hibernate jpa
source share
6 answers

A bit of history:

Entity beans were part of EJB 1 and 2. They were hell to work with, so there was an alternative. Then came the hibernate. (I do not remember these times)

Sleep mode evolved as a de facto standard in object-relational mapping. Then it was decided that a standard was needed, so the JPA specification was created that strongly influenced Hibernate.

JPA is just a specification - it defines what the ORM framework should do and what annotations it should support. JPA is implemented by many suppliers - Hibernate, EclipseLink, OpenJPA, etc.

So:

  • do not use entity beans
  • use any JPA implementation you like. Hibernate is definitely a good choice.

Update: About your secondary question in the comments:

Yes, you can use JPA with an beans beans session:

@Stateless public class YourSessionBean implements RemoteInterface { @PersistenceContext private EntityManager entityManager; // this is the JPA EntityManager } 

And you have an object manager introduced by the container and ready to work with JPA objects. Of course, you will need to create configurations for this, but this is beyond the scope of this question.

+7
source share

JPA is a specification. Hibernate is one of the implementations of the specification. Other implementations are Toplink, but there are others.

You should try to rely on the standard JPA features as much as possible. However, there are some useful Hibernate features, but they will make your application less portable if you decide to switch the implementation.

By bean, do you mean an EJB 2.x bean? This is a "dead" technology that has proven to be too complicated to use.

+3
source share

I find that for practical purposes, all JPA implementations, including sleep mode, are very similar and will work for the same use cases. However, they are usually a little, euhmmm .... temperamental if they are used for things for which they are not intended.

Since you seem to be deciding on a persistence framework, I would like to draw your attention to the fact that there are other frameworks that work very well in other use cases when JPA is difficult to use.

iBatis allows you to write simple SQL queries in a separate file and map them to java objects. This allows you to exclude SQL code from your Java code. You give the request a name and refer to that name in your code. This works very well with a larger, older database in which you need to integrate.

For some simple informal queries, things like Spring JdbcTemplate are also good without the cognitive load of previous frameworks.

+2
source share

The differences are subtle and rather difficult to understand:

  • JPA is the Java EE API for object relational mapping. You must have a JPA on every full Java EE application server on earth.
  • Hibernate is an implementation of JPA JBoss. The reason people are often confused is because JPA is somewhat inspired by hibernation.
  • Entity Bean is just a concept. This concept means that you will present your Java solutions with stored objects with Java classes. I.E. if you have customers on your system, you will likely have a Customer Bean for each customer in your database. You manage (create, update, delete, retrieve) your beans entity with JPA. People sometimes confuse Entity beans with older implementations of Entity beans in Java EE 1.4 and previous versions. In truth, you can still have Entity beans with JPA / Hibernate (or JPA / Toplink) on new Java application servers.
+1
source share

Here you can find a deeper understanding of the issue: presentation of JPA and Hibernate

+1
source share

A list of some major JPA providers is included at http://en.wikipedia.org/wiki/Java_Persistence_API in the JPA2 section.

It is best to make your own decisions about the implementation, since you, who will support your application, but always adhere to standard functions, not "add-ons"; you will win in the long run

0
source share

All Articles