1. Hibernate works well when you control the data model
iBatis works well when you need to intergate with an existing database

2. With IBatis you will get full control on SQL but hibenate deals with relationships of tables.

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 does not 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

• You want to create your own SQL's and are willing to maintain them


• your environment is driven by relational data model


• you have to work existing and complex schema's

Use Hibernate if

• 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.