The benefits of the JDBC abstraction from the Spring Framework are perhaps best demonstrated through the sequence of steps described in the following table. The table shows which tasks Spring handles and which ones you have to solve.

Table 4. JDBC in Spring - who does what?
Action Spring You

Defining connection parameters.

X

Opening a connection.

X

Setting a SQL statement.

X

Declaring parameters and providing parameter values

X

Preparation and execution of the statement.

X

Set up a loop to traverse the results (if any).

X

Execute work for each iteration.

X

Handle any exception.

X

Working with transactions.

X

Closing the connection, statement, and result set.

X

Spring Framework takes care of all the low-level tasks that make working with the JDVBC API so tedious.

Choosing an approach to accessing a JDBC database

You can choose from several approaches to form the basis for accessing a JDBC database. In addition to the three JdbcTemplate template options, a new approach using SimpleJdbcInsert and SimpleJdbcCall optimizes database metadata and uses a more object-oriented RDBMS object style an approach similar to the JDO Query framework. Once you start using one of these approaches, you can still mix and match them to take advantage of a feature from the other approach. All approaches require a JDBC 2.0 compliant driver, and some advanced features require a JDBC 3.0 driver.

  • JdbcTemplate is the classic and most popular approach to JDBC in Spring. This "low-level" approach and all others use the JdbcTemplate behind the scenes.

  • NamedParameterJdbcTemplate wraps JdbcTemplate to provide named parameters instead of the ? placeholders traditional with JDBC. This approach provides better documentation and ease of use if you have multiple parameters for an SQL statement.

  • SimpleJdbcInsert and SimpleJdbcCall optimize database metadata to limit the amount of configuration required. This approach simplifies the coding so that all you have to do is specify the name of the table or procedure and provide a Map of parameters corresponding to the column names. This will only work if the database provides adequate metadata. If the database does not provide this metadata, you must provide explicit parameter configuration.

  • RDBMS objects—including MappingSqlQuery, SqlUpdate, and StoredProcedure—require the creation of reusable and thread-safe objects during data access layer initialization. This approach is based on JDO Query, where you define a query string, declare parameters, and compile the query. Once you do this, the execute(…​), update(…​), and findObject(…​) methods can be called multiple times times with different parameter values.

Package hierarchy

The JDBC abstraction structure in the Spring Framework consists of four different packages:

  • core: The org.springframework.jdbc.core package contains the JdbcTemplate class and its various callback interfaces, as well as many related classes. A subpackage named org.springframework.jdbc.core.simple contains the SimpleJdbcInsert and SimpleJdbcCall classes. Another subpackage called org.springframework.jdbc.core.namedparam contains the NamedParameterJdbcTemplate class and its associated helper classes. See "Using JDBC Core Classes to Manage Basic JDBC and Error Handling", "JDBC Batch Operations" and "Simplifying JDBC operations with SimpleJdbc" classes.

  • datasource: The org.springframework.jdbc.datasource package contains a helper class for easily accessing DataSource and various simple DataSource implementations that can be used to test and run unmodified JDBC code outside the Java EE container. A subpackage named org.springfamework.jdbc.datasource.embedded provides support for creating embedded databases using Java database engines such as HSQL, H2, and Derby. See "Managing Database Connections" and "Support for embedded databases".

  • object: The org.springframework.jdbc.object package contains classes that expose RDBMS queries, updates, and stored procedures as thread-safe, reusable objects. See "Modeling JDBC Operations as Java Objects". This approach is modeled on JDO, although the objects returned by queries are naturally decoupled from the database. This higher level of JDBC abstraction depends on the lower level abstraction in the org.springframework.jdbc.core package.

  • support: The org.springframework.jdbc.support package contains SQLException conversion functionality and some helper classes. Exceptions thrown during JDBC processing are translated (translated) into exceptions defined in the org.springframework.dao package. This means that code using the JDBC abstraction layer in Spring does not need to implement JDBC or RDBMS specific error handling. All converted exceptions are unchecked, allowing you to catch exceptions that can be recovered by allowing other exceptions to propagate to the calling code. See "Using SQLExceptionTranslator".