Article:
  Object-Relational Mapping with SQLMaps
Subject:   Pretty good
Date:   2005-02-25 22:59:42
From:   Norbert.Ehreke
Sunil,


this is an interesting article you present. I am interested in this subject because I deal with data-centric applications, yet mostly in the fat client area. From my experience the iBatis approach has some shortcomings.


First, I think, it increases complexity by adding an additional mapping file. Or put as a question: is it really transparent what happens when a query or insert/update/delete statement is executed?


I also noticed that in the example you provide there is implicitly assumed that you need the same object (Contact) for reading and writing, however I have encountered many real life situations where this is not the case. Actually, the interfaces for reading and writing can be dramatically different.


Then there is the issue about control over the database. In fact, on the projects I have worked on the database interaction was managed mostly via Stored Procedures. This takes away all the transaction issues from the client and provides for pretty good performance as long as the DBA optimizes his SP code. I assume that iBatis would support that.


Finally, there is the issue about tabular data used directly in your application. Especially when dealing with tables, you might want to show the data in a table and transform it only when the user attempts to interact with one or more rows, which should then be converted to POJOs or JavaBeans on the fly. I don't see that iBatis supports this, or does it?


To my mind, with Tiger out, a much better approach would be the use of annotations in JavaBeans. It would be necessary to create two distinct annotation classes for reading and writing, for example ParameterAssociation (writing) and ColumnAssociation (reading). The mapping then is declared right where it belongs: in the Java source code. (I wrote this kind of API for a C# project and it works nicely.)


In essence, the iBatis technology is nice, but already obsolete and possibly cumbersome.