Summary

In this chapter we've surveyed some of the most effective data-access approaches for J2EE applications. We've considered:

• SQL-based approaches, such as JDBC and SQLJ. These can deliver very high performance, with minimal overhead, when we are working with relational databases and when O/R mapping is inappropriate. (We discussed the criteria for deciding whether to use O/R mapping in Chapter 7.) As most J2EE applications use relational databases, SQL-based approaches are very important in practice.

• Approaches based on O/R mapping, such as proprietary O/R mapping frameworks and JDO. JDO is particularly worthy of attention, as it may emerge as the standard J2EE API for accessing persistent data, whether in RDBMSs or ODBMSs.

All the approaches discussed in this chapter can be used in either the EJB container or web container of a J2EE application server. They can also easily be tested outside a J2EE application server: an important consideration, as we saw in Chapter 3. We can use any of these strategies in entity beans with BMP, but, as we have seen, BMP is unusable in many cases and imposes a complex, prescriptive model that delivers little or no benefit.

We concluded that a SQL-based approach using JDBC was most appropriate for our sample application, as it could not benefit significantly from caching in an O/R mapping layer, and because we saw in Chapter 7 that we can make effective use of stored procedures to move some of its persistence logic into the RDBMS. However, as we don't want our application's design to be dependent on use of an RDBMS, we chose to use the DAO pattern to conceal the use of JDBC behind an abstraction layer of persistent-store-independent interfaces.

As the sample application will use JDBC, we took a closer look at the JDBC API. We saw the importance (and difficulty) of correct error handling, how to extract information about the cause of a problem from a javax.sql.SQLException, and the pros and cons of JDBC PreparedStatements and Statements.

We concluded that using the JDBC API directly isn't a viable option, as it requires too much code to be written to accomplish each task in the database. Thus we need a higher level of abstraction than the JDBC API provides, even if we don't want to use an O/R mapping framework.

We examined the implementation of a generic JDBC abstraction framework, which delivers such a higher level of abstraction. We use this framework in the sample application, and it can be used in any application working with JDBC. This framework offers two levels of abstraction:

• The com.interface21.jdbc.core package, which uses callback methods to enable the framework JdbcTemplate class to handle the execution of JDBC queries and updates and JDBC error handling, relieving application code of the commonest causes of errors when using JDBC.

• The com.interface21.jdbc.object package, which builds on the com.interface21.jdbc.core package to model each RDBMS query, update, or stored procedure invocation as a reusable, threadsafe Java object, entirely concealing SQL and JDBC usage from application code. Using this package, we can greatly reduce the complexity of code using JDBC.

Another important benefit of our abstraction framework is that it enables code using it to work with a generic hierarchy of data-access exceptions, rather than JDBC SQLExceptions. This ensures that business objects never depend on JDBC-specific concepts. As all data access exceptions are runtime, rather than checked exceptions, application code is greatly simplified by being able to ignore unrecoverable exceptions. (JDO illustrates the effectiveness of this approach.)

We looked at how the sample application implements the DAO pattern using our JDBC abstraction framework. Using the abstraction framework enables us to write much simpler code than would have been required making direct use of JDBC. Using the DAO pattern enables us to use proprietary features of the Oracle target database without making our application's overall design dependent on Oracle, or even relational concepts. In this case the use of proprietary features is justified as it enables us to use efficient RDBMS constructs, and use PL/SQL stored procedures to handle persistence logic that would be much harder to implement in Java code.

This concludes our examination of data access in J2EE applications.

In the next chapter we'll look at effective use of session EJBs.