perhaps nonexistent for some simple CRUD (Create, Read, Update, Delete) appli-
cations. There are three reasons why i BATIS works well with small applications.
First, i BATIS itself is small and simple. It doesn't require a server or any sort of
middleware. No additional infrastructure is required at all. i BATIS has no third-
party dependencies. A minimal installation of i BATIS consists of only two JAR files
that total about 375KB of disk space. There is no setup beyond the SQL Mapping
files themselves, so in a matter of minutes you can have a working persistence layer.
Second, i BATIS does not impose on the existing design of the application or
the database. Therefore, if you have a small system that is already partially imple-
mented or perhaps even released, it is still easy to refactor the persistence layer to
use i BATIS . Because i BATIS is simple, it won't overcomplicate the architecture of
the application at all. The same might not be true of object/relational mapping
tools or code generators that make assumptions about the design of either the
application or the database.
Finally, if you've been working with software for any length of time, you'll likely
agree that it's almost inevitable that any small piece of software will one day
become a large piece of software. All successful software has a tendency to grow.
It's a good thing, then, that i BATIS is also very good for large systems, and that it
can grow to meet the needs of even enterprise-class applications.
iBATIS for large, enterprise systems
i BATIS was designed for enterprise-class applications. More than anything, i BATIS
has a great number of advantages in this area over other solutions. The original
creator of i BATIS has only ever had the luxury of working applications ranging
from large-scale to enterprise-class systems. These systems typically involved not
one, but many databases, none of which he had control over. In chapter 1 we dis-
cussed various types of databases, including enterprise databases, proprietary
databases, and legacy databases. i BATIS was written largely in response to the need
to deal with such databases. As a result, i BATIS has a great many features that lend
themselves well to the enterprise environment.
The first reason has been stated in other areas, but is so important that it can-
not be overstated: i BATIS does not make any assumptions about the design of your data-
base or your object model. Regardless of how mismatched these two designs are,
i BATIS will work with the application. Furthermore, i BATIS does not make assump-
tions about the architecture of your enterprise system. If you have partitioned
your database vertically by business function, or horizontally by technology, i BATIS
will still allow you to effectively work with that data and integrate it into your