First, just to help clarify things, there's two iBATIS components, the Data Mapper framework (a.k.a. SQL Maps) & the iBATIS Data Access Objects. They're packaged together but completely independent and here we're just comparing/discussing the former. The key documentation is the Developer Guide, with the very latest here in the SVN repository.

OK, on to Hibernate vs iBATIS...<br>

• While they've both involved with having your application persist & retrive data, comparing them is an "apples vs oranges" comparision, in that while they both do the job, they're significantly different in certain ways.

Fundamentally, iBATIS maps Java Objects to the results of SQL Queries, whereas Hibernate maps Java Objects directly to database tables, traditional Object-Relational Mapping. The benefits of Hibernate are that it automatically generates all the SQL for your and the cache invalidation can be more fine grained. iBATIS is more flexible especially if you are a strong SQL query writer. You have control over exactly how the SQL queries are written.

Another way of looking at it to say that Hibernate works well if you have mostly standard queries(CRUD, Find by Criteria, etc.) and if you are designing your object model first. If you are working with a legacy system or a schema designed by a DBA, iBATIS often makes a better choice. Of course, we're not discussing absolutes here, they're both much better than raw SQL!

The thing with iBATIS is that there isn't a whole lot of magic, and you get full control over the SQL, so you can see what's going on and how to change it. Compared to other frameworks, it has a shorter learning curve, but can take more time to develop and maintain, since you have to write all your queries (using Abator can short-circuit this step) and if your object model changes you have to go through all your queries and make sure to make all the necessary changes to reflect the changes in your object model.