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 Ibator 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:
These factors are primary indicators that iBATIS is a good candidate tool for your application, and this is the type of project where Ibator can make a significant impact. So how should iBATIS and Ibator be used in this case?
The Data Access Object(DAO) pattern is still the primary pattern. Ibator can generate a basic set of DAOs that match each individual table. Ibator'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 Ibator 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
saveOrder(Order order) method
somewhere (in an OrderDAO, or a service object). That method
would interact with the Ibator created DAOs for each of the 4 tables involved.
What has Ibator bought us in this case? Several things: