In the previous chapter we discussed in detail the philosophy behind i BATIS and
how the framework came to be. We also stated that i BATIS is a hybrid solution that
borrows ideas from various other methods of working with a relational database.
So what exactly is i BATIS ? This chapter will answer that question.
i BATIS is what is known as a data mapper . In his topic Patterns of Enterprise Appli-
cation Architecture (Addison-Wesley Professional, 2002), Martin Fowler describes
the Data Mapper pattern as follows:
A layer of Mappers 1 that moves data between objects and a database while keep-
ing them independent of each other and the mapper itself.
Martin does a good job of distinguishing between data mapping and metadata
mapping, which is where an object/relational mapping tool fits in. Such a tool
maps the tables and columns of the database to the classes and fields of the appli-
cation. That is, an object relational mapper maps database metadata to class meta-
data. Figure 2.1 shows an object/relational mapping between a class and a database
table. In this case, each field of the class is mapped to a single corresponding col-
umn in the database.
i BATIS is different in that it does not directly tie classes to tables or fields to col-
umns, but instead maps the parameters and results (i.e., the inputs and outputs)
of a SQL statement to a class. As you'll discover throughout the rest of the topic,
i BATIS is an additional layer of indirection between the classes and the tables,
allowing it more flexibility in how classes and tables can be mapped, without
requiring any changes to the data model or the object model. The layer of indi-
rection we're talking about is in fact SQL . This extra layer of indirection allows
i BATIS to do a better job of isolating the database design from the object model.
This means relatively few dependencies exist between the two. Figure 2.2 shows
how i BATIS maps data using SQL .
The Person class...
...has to match the PERSON table
Mapper: An object that sets up a communication between two independent objects.
—Martin Fowler in Patterns of Enterprise Architecture