Of late I’ve been playing with iBATIS persistence framework. iBATIS is a query mapper – it lets you map SQL queries to POJOs (Plain Old Java Objects). The SQL queries and mappings are externalized in XML files.

This is my initial evaluation of the framework. Most of the points are not specific to the framework – it’s more of a comparison between a full-blown O/R mapping and query mapping.

The Good

  • Simpler – Smaller learning curve when compared to full-blown O/R mappers.
  • Unlike O/R mapping, your data model does not have to match the object model because there is an additional layer of indirection (that is the SQL) between the classes and the tables. You can manipulate the query to match the object model without changing the underlying table structure.
  • Full power of SQL is in your hands. This means you can introduce multiple tables or results from stored procedures easily. (which is pretty cool.) Also since you’re writing the SQL by hand, there is more scope for optimization because you can use your DBMS-specific features like query hints, hierarchical queries etc.

The Bad

  • You still have to write the SQL. (But then you already knew that.)
  • Has no notion of parent-child relationship. One of the great things about Hibernate is the automagic updation/deletion of child records during changes to the parent record. For instance, if you’re deleting an Order record, you may want to delete all the order items. In iBATIS, you will have to manage the relationship yourselves.
  • Unit testing will be harder. Automated unit tests should be self-contained – they should not be dependent on external databases or application containers. This is where HSQLDB comes handy. I heavily use HSQLDB and Hibernate’s schema-generation tool for unit testing the persistence layer. With iBATIS, this will not be possible unless you ensure that the SQL you write is not specific to an RDBMS. This could be very hard.

When not to use a SQL Mapper

  • When you have full control over data model and object model – it may be a better idea to go for a full blown O/R M like Hibernate.
  • When the application needs a lot of dynamic queries – it may be better to stick with JDBC or write your own framework.