J2EE design decisions - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 42

nightmare. Even if your application only works with one database in produc-
tion, SQL 's lack of portability can be an obstacle to using a simpler and faster
in-memory database such as Hypersonic Structured Query Language Data-
base Engine ( HSQLDB ) for testing.

Writing JDBC code is time consuming and error-prone —You must write lots of
boilerplate code to obtain connections, create and initialize Prepared-
Statement s, and clean up by closing connections and prepared statements.
You also have to write the code to map between Java objects and SQL state-
ments. As well as being tedious to write, JDBC code is also error-prone.

■

The first two problems are unavoidable if your application must execute SQL
directly. Sometimes, you must use the full power of SQL , including vendor-specific
features, in order to get good performance. Or, for a variety of business-related
reasons, your DBA might demand complete control over the SQL statements exe-
cuted by your application, which can prevent you from using persistence frame-
works that generate the SQL on the fly. Often, the corporate investment in its
relational databases is so massive that the applications working with the databases
can appear relatively unimportant. Quoting the authors of i BATIS in Action, there
are cases where “the database and even the SQL itself have outlived the applica-
tion source code, or even multiple versions of the source code. In some cases, the
application has been rewritten in a different language , but the SQL and database
remained largely unchanged.” If you are stuck with using SQL directly, then fortu-
nately there is a framework for executing it directly, one that is much easier to use
than JDBC . It is, of course, i BATIS .

2.4.2 Using iBATIS

All of the enterprise Java applications I've developed executed SQL directly. Early
applications used SQL exclusively whereas the later ones, which used a persistence
framework, used SQL in a few components. Initially, I used plain JDBC to execute
the SQL statements, but later on I often ended up writing mini-frameworks to han-
dle the more tedious aspects of using JDBC . I even briefly used Spring's JDBC
classes, which eliminate much of the boilerplate code. But neither the home-
grown frameworks nor the Spring classes addressed the problem of mapping
between Java classes and SQL statements, which is why I was excited to come
across i BATIS .
In addition to completely insulating the application from connections and pre-
pared statements, i BATIS maps JavaBeans to SQL statements using XML descriptor
files. It uses Java bean introspection to map bean properties to prepared statement