Hibernate vs. JDBC

Question

I am working on a project that previously used Hibernate. Honestly, it seems like Hibernate complicates it more than JDBC would have. Also, it seems that a lot of the power of the relational database is lost. What are the advantages of using Hibernate over JDBC?

Answer 1

I have no experiences with hibernate but I had a look on this matter after seeing your post and found this information. Possibly useful

Answer 2

For me the main reason to use hibernate is because of it's flexibilty on new developments. You don't have to think about the database first, create all the tables and fields and then use them.

You can create classes and the tables will be created according to the annotations. It's helping very much on new projects, but is a big pain with old ones when the DB structure is already present.

Also you don't have to do magics to help with type mappings. The returned object will have already defined types like date, string, etc. and not some com.oracle..Timestamp or ..Blob types.

Also another big advantage is portability. You can write the code once and then run your code on another DB server with minor or no changes.

Answer 3

The great thing about hibernate is that is provides more than just an ORM. It also provides a Validator. The hibernate validation uses the annotations on your entity classes to instantly notify you if any constraints are being broken.

Also using Hibernate, you can easily "update" your SQL schema when you make a change in any of your entities which makes it simple to keep your DB schema and java entities in sync.

Also, by using Hibernate you get database independence, you can switch from MySQL to Oracle without re-writing any SQL statements.

Also, Hibernate integrates well with existing database connection pooling libraries giving you a boost in performance without even tying (DBCP, C3P0).

If used correctly it becomes much easier to maintain applications that use Hibernate instead of direct JDBC.

Answer 4

Hibernate isn't very complicated due to its abstraction of DBMS operations into mere POJOs. On the other hand, it does get complicated due to the fact that you have to put thought into cascade operations now being performed at object level. A lot of thought has to be put into the object/database mappings, which is somewhat easier if you have to create a new database scheme anyhow.

One main reason against Hibernate might be performance issues in batch operations. Further, legacy databases might be difficult to integrate (for example, missing primary keys will make it difficult to use a table in hibernate - of course, missing primary keys more often than never are a bad sign).

But, my experience with hibernate ain't that great so far. What I do is using a mixture of both hibernate and JDBC.

Answer 5

If you're going to use JDBC use either iBatis of Spring's JdbcTemplate. Otherwise JDBC will quickly become more complicated than Hibernate.

That being said, I can see why in certain circumstances Hibernate seems like overkill. However, using Hibernate is terribly easy if you can decide how you database is going to be designed.

The big turn off for many people for Hibernate and related ORM technologies is that your database schema has to be pretty similar to your domain classes. You don't necessarily have that with JDBC where you have much more freedom.

There are ways to have some of that freedom with Hibernate as well but then you have to know what you're doing and again JDBC becomes simpler to use.

Answer 6

One of the objectives of Hibernate and other ORM tools is to abstract the persistence of an object. Hibernate works hard to provide as much flexibility as JDBC offers while at the same time removing much of the maintenance headaches that are associated with managing SQL statements embedded into an application.

There are some additional considerations and complexity that must be tackled, but this quickly becomes a non-issue as a developer becomes adept with the framework. The complexities that were ones a problem with JDBC (connection management, connection pooling, caching, lazy-loading associations, etc.) become configuration driven and no longer an issue for a developer to contend with.

With HQL (Hibernate Query Language) the developer can achieve nearly all of the same semantics that are available in SQL. All the power of the relational database is still present and can even be reinforced in the application through column definition, foreign keys, etc. on the object meta-data (which is amazingly simple with annotations).

If you additionally leverage Spring in conjunction with Hibernate (or JPA) you will also reap the benefit of springs transaction management, connection management, etc. and still have access to the underlying JDBC connection if you find a reason to need it.

Answer 7

Hibernate isn't the only ORM out there, you know... There's also Cayenne, OJB, Torque and some others; iBatis can map your query rows to objects so you can fine-tune your queries as you please and map them to your own objects. For simple stuff you can even use the ParameterizedRowMappers of Spring JDBC and get your own objects as query rows.

Answer 8

If you are looking for an ORM that is easier to use ... you can look at Ebean ORM (at http://www.avaje.org ).

Simple API with save() and delete() ... lazy loading just works etc.

Answer 9

The primary issue I have with Hibernate is the documentation and the exceptions. I struggled to figure out how to use composite keys with annotations, and in the end I gave up and used an auto incrementing id. Every solution I found caused hibernate to throw massive errors that were completely useless in debugging the problem. Unfortunately this auto incrementing id solution is going to effect a lot of the tables in our DB. I hate that, but I can only spend so much time on that issue when there are bigger things that must be solved.

I can't even find documentation that explains the parameters in the createNamedQuery function. Most of the documentation explains how to do very specific things, without explaining all of the features and methods available. So unless you wanted to do those specific things, you basically have to hack away until you figure it out.

JDBC may not be a picknic, but if you have a thorough understanding of RDBMS and OOP, then JDBC will give you complete unimpeded freedom. Hibernate will give you short cuts and resolve complex issues, but it is not free.