As I am writing some articles about iBatis these days, I came across the iBatis "Subproject", or "Tool" Abator.
- Create database schema and build a database from it
- Write the SQLMaps for each table, including all SQL statements, i.e. typically inserts, updates, selects and deletes
- Write the domain models (transfer objects)
- Write the data access objects following the DAO pattern typically using the Spring framework's iBatis templates.
- Write the unit tests for each data access object
- You create an XML config file (rather simple) containing the information about the databas (URL, JDBC driver and the like)
- Fine tune the code generation setup, e.g., what type of DAOs should be generated: iBatis style (deprecated) or Spring DAOs.
- Add the tables you want to access into the config file
- 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, ...)
- Define the target directories
- Start Abator
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.