iBATIS data access objects - iBATIS in Action - page 219

You have a factory on the top (the DataSource interface), which creates instances
of objects that implement the Connection interface. Once you have the Connec-
tion , you can get PreparedStatement or CallableStatement objects, which in turn
provide you with ResultSet objects. You do not need to know how the DataSource
creates the connection, or how the connection creates the PreparedStatement ,
how the PreparedStatement binds the parameters to the query, or even how the
ResultSet is constructed. All of the details are irrelevant as long as you know that
when you call the Connection 's prepareStatement() method you get a Prepared-
Statement back.

10.1.1 Why the separation?

By separating the data access implementation from the data access interface, we
are able to provide a homogenous set of interfaces to heterogeneous data. An
application can access data from multiple databases, each with a different under-
lying data access mechanism using a single consistent data access API .
The JDBC API is just one type of DAO pattern. In that realm, you have a set of
interfaces, and database vendors implement them in a way that makes it possible
to use them interchangeably—for the most part. In a few cases, where vendors
feel that the interfaces do not provide the capability to do things they want to do,
they work outside the interface.
To give you an idea of how much the DAO pattern in the JDBC API simplified
its use (and yes, we really mean “simplified”), take a look at a JDBC driver imple-
mentation some time. For example, one major database vendor's implementation
of the five interfaces in figure 10.1 is composed of nine more (vendor-specific)
interfaces before getting to the five classes that actually implement them (this is
not counting any classes or interfaces that are outside of the lineage of the actual
implementing classes). One of the authors did actually build the UML for this,
and intended on putting it in here as an example, but this chapter was already too
long, and we would have had to add another page. Yes, it was that complex.
This pattern is one reason why tools like i BATIS SQL maps and O/ RM tools
are possible. Because nearly all database vendors implement the JDBC API s very
accurately, tools can be written that operate against those interfaces instead of
the underlying implementations. For the most part, those tools will work with
any vendor's implementation, and you only need to refer to the vendor's soft-
ware when you create the DataSource —from there on, you are working with the
common API .