Java Reference
In-Depth Information
still require dependencies on the third-party
implementation details.
Figure 12.1 depicts this. The arrows can be
read as “depends on,” or at least “knows about.”
As stated earlier,
iBATIS
supports plugga-
ble component design for a number of its fea-
tures. But what exactly does that mean?
Generally a
plug-in
is an extension to an appli-
cation or framework that adds new function-
ality that wasn't there before, or that replaces
existing functionality with something differ-
ent. For the most part,
iBATIS
extension
involves replacing existing functionality.
iBATIS
is designed in layers, and it is within each layer that
iBATIS
may provide
a plug-point into which you can inject your own functionality. Table 12.1 describes
the
iBATIS
layers, and summarizes the extensibility at a high level.
Figure 12.1 Example of a pluggable
framework design
Table 12.1
Layered extension summary
Extendible feature
Description
TypeHandlerCallback
Implement your own type handling logic to deal with nonstandard
databases, drivers, and/or data types.
Implement your own
CacheController
for your own cache code
or to provide support for a third-party caching solution.
CacheController
DataSourceFactory
Supply any standard
JDBC
DataSource
implementation.
TransactionConfig
Implement a custom transaction manager to work best with your
environment.
The next sections describe each of these in more detail, beginning with the most
common type of extension:
TypeHandlerCallback
.
12.2 Working with custom type handlers
As much as we'd all like relational database management systems to be standard,
unfortunately they just aren't. They all tend to implement their own
SQL
exten-
sions, as well as their own data types. Although more common data types like
binary large objects (
BLOB
s) and character large objects (
CLOB
s) are supported
by most relational databases, they are usually handled differently by each driver.
