Doing more with DAO - iBATIS in Action - page 249

value="ibatis" />
<property name="JDBC.DefaultAutoCommit"
value="true" />
</transactionManager>
<dao interface="${DaoHome}.AccountDao"
implementation="${DaoHome}.jdbc.AccountDaoImpl"/>
</context>

That is the end of the configuration—everything else is in the code that follows,
and it shows. The JDBC implementation of this DAO is over twice as many lines of
code as the Hibernate version, and nearly seven times longer than the SQL Map
version. If we include configuration files, our “lines of code” statistics look like
table 11.1. So, by eliminating configuration, we still end up doubling our total
coding effort. We are not saying that developing applications with JDBC is a bad
idea; we are simply saying that the trade-off for flexibility and minimal configura-
tion is that much more code needs to be written.

Table 11.1 Lines of code and configuration for DAO implementations

Version Configuration Code Total

iBATIS 118+8=126 53 179

Hibernate 23+20=43 141 184

JDBC 18 370 388

Looking at the JDBC DAO implementation
Because of the size of the JDBC DAO implementation, we will not be looking at the
entire class here, but we focus on some of the tricks used to build it.
The first thing that we do is build our DAO by extending the JdbcDaoTemplate
class provided by i BATIS . By doing that, we get to be a little lazy, because it man-
ages the connection for us—which means we do not have to close it in our code.
While that may seem like a trivial matter, failing to manage connections cor-
rectly in a large system will cripple it in a matter of hours (if not minutes). That
brings us to our next code-saving tip, which is creating methods to help manage
the other resources we need to use:

private boolean closeStatement(Statement statement) {
boolean returnValue = true;
if(null != statement){
try {
statement.close();