Java Reference
In-Depth Information
This is also one of the goals of the i
BATIS
DAO
: to help you provide a set of
interfaces to your applications that hide the underlying implementation of the
data access. So, if you have a Hibernate-based application that uses the
DAO
pat-
tern, you can replace that with a
SQL
Map-based implementation, or a
JDBC
-
based implementation, without having to rewrite the entire application. Instead,
all that needs to be changed is the implementations of the interfaces that the
application is using. As long as the
DAO
interface is implemented correctly, the
application will continue to function as expected.
As a rule, the
DAO
will not expose any interfaces that involve objects from the
java.sql or javax.sql packages. This means that the
DAO
is the layer of your applica-
tion where the integration with the data sources happens, and that the layers
accessing it do not have to be concerned with those low-level details. It also means
that in addition to being able to change the data access mechanism (i.e.,
SqlMap
s,
Hibernate,
JDBC
, etc.), the
DAO
pattern allows you to change the data source in a
similar fashion. Because the interface is created in a data source-agnostic man-
ner, the application does not need to know if the data is coming from Oracle or
Postgre
SQL
—or even from a non-
SQL
-based database for that matter. All it has to
deal with are JavaBeans. Where those beans originate from is irrelevant as far as
the application is concerned.
An added benefit of this sort of separation is that testing becomes much easier,
because you are not working with interfaces that are specific to the data access
method that the
DAO
uses—you are working with more common objects like List
and Map, as well as beans specific to your application.
10.1.2
A simple example
Let's start with a simple example of
how to configure and use the i
BA-
TIS
DAO
. Before we do that, look at
figure 10.2, which is the
DAO
that
we will be configuring.
This
DAO
(which is much sim-
pler than the
JDBC
example) is
composed of one interface (
Ac-
countDao
), and its implementation
(
AccountDaoImpl
). The other two
classes show one use of the inter-
face, and the
DaoManager
class,
which is the factory class used by
AccountService
<<interface>>
AccountDao
DaoManager
Dao.xml
AccountDaoImpl
Figure 10.2
An even simpler DAO (really)
