No framework meets everyone's needs out of the box, which is why it is important
that the framework provide extension points where the users can modify the behav-
ior of the framework—in other words, it is essential that the framework be pluggable .
Although iBATIS is open source software, and end users could easily modify the
code to do whatever they need, it is important to provide a consistent and sup-
portable means of extending the framework. Otherwise, every time a new version
of iBATIS was released, the users who had modified their copies of iBATIS would
have to merge their changes and recompile the entire framework.
iBATIS provides a number of levels of customization. First, as a general best
practice, iBATIS uses interfaces between design layers of the framework. This
means that even if there isn't a standard extension supported by the framework,
the most an end user would need to do is implement the interface and replace
the standard implementation with their own. We'll see an example of this later in
this chapter when we discuss customizing the SqlMapClient interface.
For areas that are more likely to require customization on a per-application, or
per-platform, basis, iBATIS provides a standard pluggable component architecture
for features such as type handlers, transaction managers, data sources, and cache
The next sections examine each of these in detail. Let's first discuss general
concepts in plug-in architecture.
12.1 Understanding pluggable component design
A pluggable component design is generally made up of three parts:
The interface describes the intended functionality and is a contract that all imple-
mentations must follow. The interface describes what the feature does.
The implementation is the specific behavior that describes how the feature
works. It may have dependencies on third-party frameworks or even large infra-
structure, such as an advanced caching system or application server.
The factory is responsible for binding the implementation to the interface
based on some configuration. The whole idea is to ensure that the application is
not dependent on anything other than the single consistent interface to the
framework. The framework would be failing at its job if the application were to