Java Reference
In-Depth Information
Object/relational mapping
Object/relational mapping (
O/RM
) was designed to simplify persistence of
objects by eliminating
SQL
from the developer's responsibility altogether. Instead,
the
SQL
is generated. Some tools generate the
SQL
statically at build or compile
time, while others generate it dynamically at runtime. The
SQL
is generated based
on mappings made between application classes and relational database tables. In
addition to eliminating the
SQL
, the
API
for working with an
O/RM
tool is usually
a lot simpler than the typical
SQL
API
s. Object/relational mapping is not a new
concept and is almost as old as object-oriented programming languages. There
have been a lot of advances in recent years that make object/relational mapping a
compelling approach to persistence.
Modern object/relational mapping tools do more than simply generate
SQL
.
They offer a complete persistence architecture that benefits the entire applica-
tion. Any good object/relational mapping tool will provide transaction manage-
ment. This includes simple
API
s for dealing with both local and distributed
transactions.
O/RM
tools also usually offer multiple caching strategies for dealing
with different kinds of data to avoid needless access of the database. Another way
that an
O/RM
tool can reduce database hits is by lazy loading of data. Lazy loading
delays the retrieval of data until absolutely necessary, right at the point where the
data is used.
Despite these features, object/relational mapping tools are not a silver-bullet
solution and do not work in all situations.
O/RM
tools are based on assumptions
and rules. The most common assumption is that the database will be properly nor-
malized. As we will discuss in section 1.4, the largest and most valuable databases
are rarely normalized perfectly. This can complicate the mappings and may
require workarounds or create inefficiencies in the design. No object relational
solution will ever be able to provide support for every feature, capability, and
design flaw of every single database available. As stated earlier,
SQL
is not a reli-
able standard. For this reason, every
O/RM
tool will always be a subset of the full
capabilities of any particular database.
Enter the hybrid.
1.1.2
Understanding the iBATIS advantage
i
BATIS
is a hybrid solution. It takes the best ideas from each of these solutions and
creates synergy between them. Table 1.1 summarizes some of the ideas from each
of the approaches discussed earlier that are incorporated into i
BATIS
.
