[Tech] Generate the Persistence Layer for iBatis from the Database Schema

As I am writing some articles about iBatis these days, I came across the iBatis "Subproject", or "Tool" Abator.

I think it was obvious from my recent posts, that I have quite some sympathies for the iBatis project. However, writing the persistence part with iBatis (and also other persistence framworks) still means a lot of typing. Typically you have to create the following artifacts:

1. Create database schema and build a database from it
2. Write the SQLMaps for each table, including all SQL statements, i.e. typically inserts, updates, selects and deletes
3. Write the domain models (transfer objects)
4. Write the data access objects following the DAO pattern typically using the Spring framework's iBatis templates.
5. Write the unit tests for each data access object

So counting this means you have to write four artifacts (assuming the database is existing) for each table you want to access. This is obviously awkward. So, how can Abator help you: Actually Abator works like so:

1. You create an XML config file (rather simple) containing the information about the databas (URL, JDBC driver and the like)
2. Fine tune the code generation setup, e.g., what type of DAOs should be generated: iBatis style (deprecated) or Spring DAOs.
   
3. Add the tables you want to access into the config file
4. Make some optional configuration steps (like, should the pojo be named different to the table, should some fields in a table be omitted, should they by named differently in the POJO, ...)
5. Define the target directories
   
6. Start Abator

Then Abator creates the SQLMaps, the model beans, the DAO in the desired technology (so you get steps 2-4 in the upper artifact-list)! Now, the question arises, if this makes sense, as you also have to write the Abator definition XML and learn to use the tool. Moreover this is a "one time" thing: the generation step will be done only once and then you will most probably modify the generated classes and SQLMaps to better fit your needs.

I personally think I will make sense in many cases, particularly when the data base consists of many tables. Writing the Abator config is rather simple and it generates all the artifacts of n-classes within one step. These generated artifacts are often a robust point to start from, much faster then writing everything from scratch.

Additionally it very easy to understand Abator and allows "newbies" to get a set of SQLMaps, objects and DAOs plus one example class for each table showing how to use the DAOs. This helps to get a quick an easy introduction into the iBatis concepts.

Remark: Please read the design philosophy part of the Abator documentation. It is clearly mentioned that this strategy is a database-model driven strategy. If this is fitting for the project it seems to be great, if the project or developer focus is more a object-model driven one (which is seldom the case in enterprise projects) this approach might not be fitting.