Ibatis V Hibernate

For those that have been following the “Taking the Java plunge” series, you will note that I have chosen iBatis as the framework to use with the database. By reading the various mailing lists that I do, I get the distinct impression that Hibernate is the flavour of the month and this was worrying me, in that I couldn’t understand why.

A brief discussion on the iBatis mailing list has just shed an interesting perspective on the differences between the iBatis and Hibernate, and since this made the light of understanding pop up in my head, I thought I would share it here.

In simple terms, Hibernate maps Java Objects to database tables. iBatis maps Java Objects to SQL statements.

Therefore, if you use Hibernate, as a programmer you don’t have to know SQL – it is generated for you. This is fine, and particularly useful if you are doing a insert or delete operations, but you loose the power that SQL gives you in the SELECT parts of your application.

SQL was developed specifically as a set processing language, and the database engines that use it have optimised their access of data around those concepts. Therefore if you need to do any sort of complex processing it is much more efficient to do it in the SQL rather than do it by processing in Java.

Generally speaking applications, particularly anything more than simple CRUD updates are going to do far more SELECTs than anything else.

So now I know why I was so attracted to iBatis. It stems from the fact that I tend to automatically normalise the database design as I do it. I knew that my database design for the family tree application was going to involve a single table called persons that would hold information about complete families, and that I was going to do want to do fairly complex joins on verious versions of this table. One of the simpler examples is something like :-

SELECT f.*,c.* from persons as f join persons as c on c.father = f.id where f.id = 23;

So iBatis will naturally map the results of a query like this into a complex object (an object which has got attributes for the father and a collections object such as a list for the children). I never got far enough into Hibernate to know whether you can do this or not. I am led to believe its a bit difficult.

So I was attracted to iBatis for the control that it gave me over the database processing I was doing.

This leads to one element of the issue that I think I need to address. It has been argued that in developing a web project you don’t want the programmers to have to come to grips with SQL. Therefore Hibernate is the way to go.

To me that is nonsense. To do a good job in developing any application you need to use the right tools for the job. In the corporate sense, if you want to avoid your web application programmers having to also learn SQL, then choose a tool that allows a separation of responsibility between those that need to know Java and those that need to know SQL.

Tapestry provides for the separation of HTML coding from the java, use iBatis to provide the separation of the Java from the SQL.