We have covered a lot of ground in this chapter. We introduced Spring's JDBC framework, including the use of a DataSource to obtain connections, and the translation of uninformative SQLExceptions to a number of subclasses of Spring's DataAccessException.
We looked at the following:
How to use JdbcTemplate, Spring's central class for JDBC database access. You saw examples using JdbcTemplate for querying and updating data.
The RDBMS Operations abstraction layer, which is a higher abstraction than the JdbcTemplate. We looked at MappingSqlQuery for querying, and how to perform updates and inserts with the SqlUpdate class.
The UpdatableSqlQuery, as an alternative way to update data, which can be appropriate if you want to iterate through data as you update it.
Strategies for generating and capturing primary keys during database inserts — a common challenge.
The StoredProcedure class, Spring's sophisticated approach to simplifying stored procedure invocation.
After this, we felt we were ready to tackle some more advanced issues:
We considered some issues you might encounter running JDBC code in an application server.
We saw how to provide customized SQLException translation by overriding the default exception translator provided by Spring.
We saw how to handle large objects such as BLOBs and CLOBs using both JdbcTemplate and RDBMS Operations support.
We looked at batch updates.
We saw how to handle a stored procedure that returns a ResultSet.
Spring's JDBC support enables you to write far less code than in traditional JDBC usage. That code is typically less error prone — for example, connection leaks can no longer result from buggy application code — and more portable. Instead of wrestling with the mechanics of resource management and JDBC's incidental API complexity, you can focus on the SQL you wish to execute. Thus, Spring JDBC is a good example of the Spring value proposition: taking care of plumbing to allow you to focus on your domain.