Object Relational (OR) Mapping: Hibernate and iBatis…The Down Side

I’ve been having a lot of discussions recent regarding the use of OR mapping tools such as Hibernate or iBatis.  The evangelists point out the ease of use, decoupling of SQL from the code, automatic caching (if turned on), and transparent persistence of POJOs (Plain Old Java Objects).  I can’t argue.  Both Hibernate and iBatis are pretty cool and I am very excited to use them.  However, there is one point that negates its usefulness in larger organizations: Hibernate and iBatis relegates the duties of database query development and maintenance to the Java/Application development team (and away from the experts).

In larger organizations, there usually is a dedicated Database team that develops and maintains the DB tables, integrity, and SQL queries (or stored procedures).  They are the experts and quite often for projects I simple give them the database requirements and they will produce everything from the tables to the stored procedures. When it goes smoothly it is amazing and can make the whole database development aspect a “gray” box.

If one uses an OR mapping tool, the Database team no longer can develop or maintain the queries without significant support from the application development team.  And if you uses something like Hibernate’s query language (HQL), well, the DB folks will just laugh at you when asking for their help.  Now I’m not saying that it is impossible to involve the database team if you’re using Hibernate or iBatis, but just that it becomes significantly more difficult and the clear delineation of duties and responsibilities is weighted towards the application development team.

So, what is the best structure/framework to have?  I’m a fan of the following:

  1. Stored Procedures: The database development team can have fully control and responsibility.  It also allows multiple applications to access the same stored procedures (seems a bit more object oriented to me).
  2. iBatis w/ Stored Procedures:  I do like iBatis, but only used as a framework to separate out the connectivity and database calls away from the POJOs and into XML files.  I am a big fan of being able to see and/or change all the connectivity and procedure names/parameters via an XML file.
  3. Spring DAO w/ iBatis:  Every application should have a DAO (Data Access Object) layer.  I won’t go into all the reasons here, but needless to say, it create more flexible and maintainable code.  Many times I’ve encountered different developers either not using DAOs or creating their own that are questionable.  Spring (or the iBatis’ DAO) provides an excellent framework that easily integrates with iBatis.  One cool thing it does is takes care of closing the connections for you!

By using the above three frameworks, one can maintain standardization and a degree of good design across a larger development team.  You don’t have to worry about 3 different types of DAOs or that the SQL is intermixed within the code or that the SQL coder’s expertise mainly lies in Java (and the true experts aren’t fully being utilzed).  While this structure can apply to smaller organizations, I think the primary benefit will be found in larger, more segmented organizations.

About Geoffrey Bourne

CTO at Ladders

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s