Hibernate Vs. iBatis?

Hibernate Vs. iBatis?
Hibernate or iBatis or both ? Which is better?
Which one to use and when?

These are the few questions that continuously get asked in most of forums.
What’s really difference between two and really more importantly when should I use one over the other. Its pretty interesting question because there are major differences between iBatis and Hibernate.

Within in the java persistence there is no one size, fits all solution. So, in this case Hibernate which is a de facto standard is used in lot of places.

Let us consider a scenario where Hibernate work great for initial model. Now Suddenly if you are using stored procedures, well we can do it in Hibernate but its little difficult; ok we map those, all of sudden we got some reporting type of queries, those don’t have keys have group bys; with some difficulty here we can use name queries and stuff like that, but now starts getting more complicated, we have complex joins, yes you can do in hibernate, but we can’t do with average developer. We have sql that just doesn’t work.

So these are some of the complexities. One of the other things I find is, if am looking at an application that doesn’t work very well with an ORM, aside from these considerations of using stored procedures, already using SQL, complex joins. In other words, Hibernate works very well if your data model is well in sync with object model, because ORM solutions like Hibernate map object to tables. However, let’s suppose data model is not in sync with object model, in this case you have do lot of additional coding and complexities are entering into your application, start coming the beyond the benefits of ORM. So, again all of sudden you are noticing that the flow is gone; our application is becoming very very complex and developers can’t maintain the code.

This is where the model starts breaking down. One size does not fit all. So this is where I like to use iBatis; as the alternative solution for these type of situations, iBatis maps results sets to objects, so no need to care about table structures. This works very well for stored procedures, works very well for reporting applications, etc,.

Now the question is , does it work well for simple CRUD applications? Well, it works because what we have to write is sql. Then why not use Hibernate for that?

You can start see Some of the decision criteria that comes into play. So one of the other follow on questions that typically get is , can I use both? That’s really interesting question! because the answer is sure.

But,such a thing will never ever exists is java persistence world. However we can kind of use both to create this little hybrid. So think of this kind scenario, we have very large application where Hibernate is working very well for it, but we have a reporting piece that just is a real nag , its query only , so we can do is, we can use iBatis to pull up the queries for reporting piece and still use Hibernate for all the operational stuff and updates. This model actually works well, it doesn’t break the transactional model, and it doesn’t affect any of the primary & secondary caches with a Hibernate. It’s a good solution.

* Use iBatis if
o You want to create your own SQL's and are willing to maintain them
o your environment is driven by relational data model
o you have to work existing and complex schema's
* Use Hibernate if
o your environment is driven by object model and wants generates SQL automatically


The message is,

* One size does not fit all the java persistence and the important to know there are other solutions besides the traditional ORMs, and that would be iBatis.
* Both the solutions work well, given their specific domain.
* Look for the opportunity where you can use both.

What is iBatis ?

* A JDBC Framework
o Developers write SQL, iBATIS executes it using JDBC.
o No more try/catch/finally/try/catch.
* An SQL Mapper
o Automatically maps object properties to prepared statement parameters.
o Automatically maps result sets to objects.
o Support for getting rid of N+1 queries.
* A Transaction Manager
o iBATIS will provide transaction management for database operations if no other transaction manager is available.
o iBATIS will use external transaction management (Spring, EJB CMT, etc.) if available.
* Great integration with Spring, but can also be used without Spring (the Spring folks were early supporters of iBATIS).


What isn’t iBATIS ?

* An ORM
o Does not generate SQL
o Does not have a proprietary query language
o Does not know about object identity
o Does not transparently persist objects
o Does not build an object cache

Essentially, iBatis is a very lightweight persistence solution that gives you most of the semantics of an O/R Mapping toolkit, without all the drama. In other words ,iBATIS strives to ease the development of data-driven applications by abstracting the low-level details involved in database communication (loading a database driver, obtaining and managing connections, managing transaction semantics, etc.), as well as providing higher-level ORM capabilities (automated and configurable mapping of objects to SQL calls, data type conversion management, support for static queries as well as dynamic queries based upon an object's state, mapping of complex joins to complex object graphs, etc.). iBATIS simply maps JavaBeans to SQL statements using a very simple XML descriptor. Simplicity is the key advantage of iBATIS over other frameworks and object relational mapping tools.