ORM with iBatis SQLMaps

I’ve already written about ORM (object-relational mapping) on Dagblog in
A Whirlwind Tour of ORM.
That post dates from when we were experimenting heavily with ORM and looking for the right tool.
Hibernate deservedly came out on top.
When we moved from ordinary SQL to an ORM layer,
we ran into several problems right away.

Mapping objects to our existing database model proved difficult. The biggest
headaches came from composite keys. On the whole, the opposite approach looks better to me.
Model the relations with objects first and generate
the database model from them.

In When Should You Use EJB? I pointed to
some interesting views on alternatives to EJB without digging into the individual topics
that came up. I did mention these disadvantages of Hibernate as I saw them.
Someone in the discussion suggested an alternative,
iBatis SQLMaps.

If you’ve never heard of iBatis SQLMaps, there’s a very good article
by Sunil Patil, Object-Relational Mapping with SQLMaps. I
personally like iBatis SQLMaps because you use ordinary SQL
for the mapping itself. In some cases, especially when you have a very
complex existing database schema, SQLMaps strikes me as a better fit.

Incidentally, here are ten reasons to use iBATIS SQL Maps from the official
project site.

• 10 Works with any database that has a JDBC driver (no plugins required)
• 9 Configurable caching (including dependencies)
• 8 Local and Global transaction support and management (JTA)
• 7 Simple XML mapping document structure
• 6 Supports Map, Collection, List and Primitive Wrappers (Integer, String etc.)
• 5 Supports JavaBeans classes (get/set methods)
• 4 Supports complex object mappings (populating lists, complex object models etc.)
• 3 Object models are never perfect (no changes required!)
• 2 Database designs are never perfect (no changes required!)
• 1 You already know SQL, why waste time learning something else?

The eleventh reason, and an important one for me, is support in the Spring Framework.