Should I use Hibernate for the next project? How does it compare to JDBC

This question get's asked a lot. And the first answer is most of the times: That is comparing apples and oranges. And of course that is true. But if you are a little kid apples are round and tasty and so are oranges, so it is a reasonable question what exactly is the difference between apples and oranges?

Both (Hibernate and JDBC not apples and oranges) are used for tying application logic to your database. Hibernate is actually using JDBC. Actually you can use Hibernate in a very similiar way as JDBC. So how exactly does one work with JDBC?

You create a connection, create query from that (using SQL), change the objects (carefully keeping track of what you changed), transform you change log in SQL Statements and send those to the database (using the old or a new connection).

If you don't like Hibernate, but are forced to use it you do it the same way:
start a session, create a query from that (using HQL), disconnect the objects, change the objects, (carefully keeping track of what you changed), start a new session and use it to store the new state of the objects in the database.

So you are saving, the DML statements for storing the objects, therefore you have to learn HQL, Hibernate, and all the weird error messages you get from it.

But you can use Hibernate very differently:

Open a session, query for some objects (using Criteria), work with these and commit the session.

That is when the real power of hibernate reveals itself. You are using neither HQL nor SQL, at least for the standard tasks. This takes away a lot of the ugly kind of error you only get when you actually run the code. You don't have to keep track what exactly you changed. Hibernate is doing that for you. At least on the first go you don't have to worry when to load exactly what piece of information, instead Hibernate will do it on the fly for you (and of course you will have to control it in some cases where Hibernates choices aren't the right once).

But you can benefit from Hibernate even more: Do the design in the domain model, i.e. design you model classes the way they should look like from an OO perspective, then add the necessary Hibernate Annotations, thereby deciding on mapping strategies for inheritance and the like. In my experience this results in a richer, more expressive domain model and in a cleaner database design.

The reason for this is, that by using this approach you are bringing the power of refactoring to the database! How about an experiment. Go to your favorite database administrator and tell her that someone was ignoring the naming conventions. A couple of table names (about 70) and a couple of columns (about 600) have to be changed, oh and someone hast to change all the sql statements as well. How are your chances to get this refactoring done? Zero? Not too long ago I had exactly that kind of change as a task. Iwas done after 4 hours! It was quite easy. I did the changes to the domain model using the refactoring features of the IDE, that was it (almost). I had to change about 4 or 5 special purpose HQL Statements, and semi automatically create a change script for the database. Yes this was on an application that was installed on a client side, so I had to take care of migration scripts.

I am not saying that you should do this kind of refactoring, but how often do you refactor your database? It is still considered voodoo science but with Hibernate you can at least use a powerful IDE and doen't have to put up with the crappy stuff you get from database tool vendors. With other tools not many people go through the trouble of changing a column name, because it is wrong in one way or the other. In Java I never stop changing a method or attribute name that I consider wrong as long as it isn't used in some public API of course.

As usual it comes at a cost.

• Hibernate has learning curve. People of hibernate.org claim do have learned hibernate in two weeks. I don't think so. They might know enough to use it. But just as with SQL or Java or whatever, it takes time to really master it.
• Hibernate is no magic pixy dust. It makes decision and uses default. If those don't fit your needs, you might encounter problems, e.g. performance hits. In these cases you have to change the mapping, write HQL, or even SQL or do whatever needs doing to fix the problem.
• If you are working with a legacy database or can't use the approach described above then the benefit from using Hibernate is smaller.

If you disagree, let me know in the comments. ff you agree, let me know as well.