Abator Philosophy and Apology

Some philosophical questions might be raised by this tool because the tool is more focused on database tables than on the domain model. We will take a few paragraphs to talk about this approach.

First of all, this tool does what it does. We are not making any kind of statement about how projects should, or should not, be structured. In general we are strong proponents of rich domain models - but creating a rich domain model is quite a different thing from answering the question of how that model should be persisted.

If your particular design philosophy is that the domain model drives all decisions, and that the database design is subservient to the domain model, then this tool - and iBATIS itself - may not be the proper fit for your application. In that case, we would suggest taking a serious look at Hibernate - it may fit more closely with your application design and philosophy.

But not all projects fit that paradigm. Very few truly enterprise class applications do. iBATIS and Abator can be of great help in projects where database design is seen as a co-equal to domain object design. iBATIS is not an object relational mapper, and does not attempt to transparently persist objects. So it falls on application developers to write SQL to interact with database tables.

In large or enterprise class projects, many of these factors are quite common:

Database design is often a separate function (with separate management) from OO domain design
Database designers do not have OO tools (like inheritance), so they don't think in OO terms
Application designers do not have complete control over the final form of database tables. For example, the data that seems to fit in one object for the application, may be split into several tables in the database.
The database design often ends up quite different from the OO design, leading to a significant mismatch between tables and objects.

These factors are primary indicators that iBATIS is a good candidate tool for your application, and this is the type of project where Abator can make a significant impact. So how should iBATIS and Abator be used in this case?

The Data Access Object(DAO) pattern is still the primary pattern. Abator can generate a basic set of DAOs that match each individual table. Abator's DAOs are transaction neutral. This means that it is easy to extend the DAOs to add transaction attributes if more than one table is involved in a transaction. Or, you could create another DAO (or service method) that more closely matches the persistence needs of a domain object and make use of one or more Abator DAOs in a single transaction.

As an example, consider a typical Order object - the typical header/detail problem. In some environments such an object would be persisted into at least 4 tables - two key tables, a "header" table, and a "detail" table (again, we are not making any kind of statement about whether this is "correct" design, just stating a fact). Your application should still interact with interact with the Order object, and there might be a saveOrder(Order order) method somewhere (in an OrderDAO, or a service object). That method would interact with the Abator created DAOs for each of the 4 tables involved.

What has Abator bought us in this case? Several things:

Reuse - it is likely that some tables will need to be accessed from multiple different DAOs or service methods. Creating a DAO for each table promotes reuse and consistency within the application.
Database abstraction - a service layer typically defines persistence in your application. Those methods can be stabilized fairly quickly. As database design evolves:
1. Abator can quickly regenerate the DAOs as the tables change
2. The service methods can be modified as necessary
3. Higher layers in the application remain unchanged
Developer productivity - generating table based DAOs is quick and repeatable and error free. Developers can concentrate on Object persistence, and on complex join queries if needed.
Fewer defects - because the most tedious and error prone part of any application (getting the SQL to match the objects) is automated.