This is an excerpt from a discussion I had with the developers at the company I am contracting to. Let me know your thoughts.

Just wrapping up a project and thought I would share my experience of how God awful it was working with Hibernate on this project.

 

This post sums up the bulk of my problems. Hibernate definitely has the high-profile backing of the Java community, is JPA compliant now and Gavin King is pretty much the DHH in the Java Persistence world. Not to mention he’s probably making some good coin at his new home (JBoss). However it is my belief that it only works well for greenfield schemas. That is, create your schema the way Hibernate wants them but if you are thinking of trying to use Hibernate on a legacy schema, that perhaps isn’t well formed you are in for a world of hurt.

 

iBatis on the other hand is the working man’s ORM. In fact, I think I like it because I (and probably you) have created something similar back in the day before all these formalized ORMs. It simply and elegantly maps your sql results to an object of your choosing. You state the SQL you want to execute, be it a plain-jane SQL statement/stored proc/view and it automatically maps the resultset back into POJOs. It also easily lets you override the default mapping behaviour.

 

Defining 1:1, 1:M, M:M relationships are far more straightforward than in Hibernate, ESPECIALLY when your database was not designed by you and you have no control over primary keys, foreign keys, etc... (i.e. the BKG schema has no foreign keys.... Hibernate really likes those...)

 

The solution to the problem in my post (linked above) was to create a view for Hibernate to map to. Unfortunately, I could not update through that view so I had to code custom <sql-update>, <sql-insert> and <sql-delete> tags for my mapping. And believe me, that is literally a bolt on solution Hibernate provides without any frills. You have to actually *run* the hibernate mapping in debug mode to figure out what order hibernate will pass parameter values to your <sql-*> tag. That is extremely fragile! The next person that touches your mapping, perhaps to add or remove a property, will inevitably break the <sql-*> functionality. I absolutely hated using the <sql-*> functionality because of this reason.

 

What I did at home was I read the iBatis SqlMapper documentation. After that, it took me 30 mins to implement functionality that took me a week to implement in Hibernate. That’s right, a week. A week sounds like a long time, but I had faith that Hibernate would give me a way to map my pojos without resorting to the <sql-*> tags, but it was only an illusion which I realized after reading the responses (or lack there of) to the post I made on the Hibernate forums. So most of the time spent was learning that Hibernate doesn't easily support what I needed it to.

 

Why is Hibernate more popular? It writes your sql for you, iBatis doesn’t. However, iBatis does have a code generator by the name of Abator (along with an Eclipse plugin) which will do 80% of the grunt work for you by creating your model object, sql mapping files, etc... based off a set of database tables.

 

So in conclusion, I think we have to be open to using technologies other than what is officially mandated; when it makes sense. I don’t think it’s healthy to say "do we use Hibernate OR iBatis for all projects" because in my case iBatis is definitely something that would have made my life easier, saved the firm money and probably would make the DAs more comfortable knowing that some ORM is not creating Voodoo SQL on-the-fly.