iBatis DAO

The
Data Access Object pattern in the Core J2EE Pattern Catalog
suggests that while creating a robust J2EE application, you should
abstract and encapsulate all access to a data source behind a
common API. In terms of programming, what this means is to create
an interface defining all of the business methods that your
application needs. Inside your application, you use this interface
when you want to interact with your data store, and then create a
separate class that implements this interface and has the logic
for interacting with that particular data store.

For example, consider the sample application developed in the
article iBatis: SQL Maps. This is a Struts application that allows you to
fire SELECT, INSERT, UPDATE and DELETE SQL queries on a
CONTACT table. In this application, we are using SQL
Maps as the persistence framework. Now say we want to change this
application so that the CONTACT table is stored in an
XML file instead of a RDBMS, or want
to use Hibernate for SELECT queries and SQL Map for
the other three queries, perhaps because Hibernate provides better
support for caching. This will be very hard to implement, and if we
are able to change it at all, it won't be a very clean
solution.

A better approach for this type of problem would be to create a
ContactDAO interface and define business methods for
SELECT, INSERT, UPDATE, and
DELETE queries in this interface. Then you'd create
separate classes containing persistence logic for each method. So
there would be a class that knows how to interact with the
CONTACT table using SQL Maps, another class that
knows how to interact with the CONTACT table if it is
stored in a XML file instead of a RDBMS, and so on.
Inside your application, you'd choose from different
implementations of ContactDAO, depending on your requirements. This
relationship is shown in Figure 1.

iBatis Data Access
Object (DAO) is an open source framework now hosted by Apache
and targeted at solving these type of problems. It provides you
with an infrastructure for creating applications based on the DAO
pattern. What this means is that you can create a XML file and
declare that XMLContactDAO.java is the implementation class
for ContactDAO, which knows how to read and write
contacts in an XML file instead of a RDBMS.
SQLMapContactDAO is an implementation class that
knows how to interact with the CONTACT table using SQL
Maps as its persistence framework. Inside your application, you ask
the DAO framework for an implementation of ContactDAO for
XML, and it will provide you with an XMLContactDAO
object. Also, the DAO framework provides you with a uniform
interface to handle transaction management, irrespective of what
persistence mechanism you use. It will also take care of the
low-level details of connection management and initializing
persistence frameworks.

This article is a step-by-step guide on how to use the iBatis
DAO framework in your application. We will start by looking at how
to change our sample application developed in the SQL Maps article
to use the DAO framework. Then we will talk about the architecture
of the DAO framework. Next we will look at which transaction managers
are supported in DAO framework, and will finish with a section on how to
create your own transaction manager.

Sample Application

We will start by changing our sample application developed in
the SQL Maps article to use the DAO framework.

DAOMap.xml file is a deployment descriptor for your
iBatis DAO framework. <daoConfig> is the root
element. Each <context> element represents one
persistence mechanism. In our example, we will use only SQL Maps for
persistence, so we so have only one <context>
element. Every persistence mechanism should have one
<transactionManager> element, which represents
the manager used for getting a connection to the underlying data
store and marking the transaction boundary. We will talk more about
transactionManager later.

The <context> element also contains a list of
DAOs for the given particular persistence mechanism. In our
example, we want to create a ContactDAO, which will use
SQL Maps for persistence, so we will add one
<dao> element defining
SQLMapContactDAO.