Advantages provided by iBATIS, which are the same as those provided by other solutions
iBATIS encapsulates and externalizes
SQL such that it is outside of your
application code. It describes an API
similar to that of a stored procedure,
but the iBATIS API is object oriented.
iBATIS also fully supports calling
stored procedures directly.
Business logic is kept out of
the database, and the appli-
cation is easier to deploy and
test, and is more portable.
iBATIS allows SQL to be written the
way it was intended to be written.
There's no string concatenation, “set-
ting” of parameters, or “getting” of
iBATIS doesn't impose on your
application code. No precom-
piler is needed, and you have
full access to all of the fea-
tures of SQL—not a subset.
iBATIS provides features for dynami-
cally building queries based on
parameters. No “query-builder” APIs
iBATIS doesn't force SQL to
be written in blocks of concat-
enated strings interlaced with
iBATIS supports many of the same fea-
tures as an O/RM tool, such as lazy
loading, join fetching, caching, runtime
code generation, and inheritance.
iBATIS will work with any com-
bination of data model and
object model. There are nearly
no restrictions or rules to how
either is designed.
Now that you understand the roots of i BATIS , the following sections discuss two of
the most important qualities of the i BATIS persistence layer: externalization and
encapsulation of the SQL . Together, these concepts provide much of the value
and enable many of the advanced features that the framework achieves.
One of the wisdoms learned in the last decade of software development has been
to design one's systems to correspond to different users of the subsystem. You want
to separate out the things that are dealt with by different programming roles such
as user interface design, application programming, and database administration.
Even if only a single person is playing all of these roles, it helps to have a nicely
layered design that allows you to focus on a particular part of the system. If you
embed your SQL within Java source code, it will not generally be useful to a
database administrator or perhaps a . NET developer who might be working with the
same database. Externalization separates the SQL from the application source
code, thus keeping both cleaner. Doing so ensures that the SQL is relatively
independent of any particular language or platform. Most modern development
Search WWH ::