1.2 Where iBATIS fits
Nearly any well-written piece of software
uses a layered design. A layered design
separates the technical responsibilities
of an application into cohesive parts
that isolate the implementation details
of a particular technology or interface.
A layered design can be achieved in any
robust ( 3GL/4GL ) programming lan-
guage. Figure 1.2 shows a high-level
view of a typical layering strategy that is
useful for many business applications.
You can read the arrows in figure 1.2
as “depends on” or “uses.” This layering
approach is inspired by the Law of
Demeter, which in one form states,
“Each layer should have only limited
knowledge about other layers: only lay-
ers closely related to the current layer.”
The idea is that each layer will only
talk to the layer directly below it. This
ensures that the dependency flows only in one direction and avoids the typical
“spaghetti code” that is common of applications designed without layers.
i BATIS is a persistence layer framework. The persistence layer sits between the
business logic layer of the application and the database. This separation is impor-
tant to ensuring that your persistence strategy is not mixed with your business
logic code, or vice versa. The benefit of this separation is that your code can be
more easily maintained, as it will allow your object model to evolve independently
of your database design.
Although i BATIS is heavily focused on the persistence layer, it is important to
understand all of the layers of application architecture. Although you separate
your concerns so that there are minimal (or no) dependencies on any particular
implementation, it would be naive to think that you can be blind to the interaction
among these layers. Regardless of how well you design your application, there will
be indirect behavioral associations between the layers that you must be aware of.
The following sections describe the layers and describe how i BATIS relates to them.
Figure 1.2 A typical layering strategy following
the Law of Demeter