The value-add provided by the Spring Framework JDBC abstraction is perhaps best shown by the sequence of actions outlined in the table below. The table shows what actions Spring will take care of and which actions are the responsibility of you, the application developer.
Table 12.1. Spring JDBC - who does what?
|Define connection parameters.||X|
|Open the connection.||X|
|Specify the SQL statement.||X|
|Declare parameters and provide parameter values||X|
|Prepare and execute the statement.||X|
|Set up the loop to iterate through the results (if any).||X|
|Do the work for each iteration.||X|
|Process any exception.||X|
|Close the connection, statement and resultset.||X|
The Spring Framework takes care of all the low-level details that can make JDBC such a tedious API to develop with.
You can choose among several approaches to form the basis for your JDBC database access. In addition to three flavors of the JdbcTemplate, a new SimpleJdbcInsert and SimplejdbcCall approach optimizes database metadata, and the RDBMS Object style takes a more object-oriented approach similar to that of JDO Query design. Once you start using one of these approaches, you can still mix and match to include a feature from a different approach. All approaches require a JDBC 2.0-compliant driver, and some advanced features require a JDBC 3.0 driver.
Spring 3.0 updates all of the following approaches with Java 5 support such as generics and varargs.
JdbcTemplate is the classic Spring JDBC approach and the most popular. This "lowest level" approach and all others use a JdbcTemplate under the covers, and all are updated with Java 5 support such as generics and varargs.
JdbcTemplate to provide named parameters
instead of the traditional JDBC "?" placeholders. This approach
provides better documentation and ease of use when you have multiple
parameters for an SQL statement.
SimpleJdbcTemplate combines the most frequently used operations of JdbcTemplate and NamedParameterJdbcTemplate.
SimpleJdbcInsert and SimpleJdbcCall optimize database metadata to limit the amount of necessary configuration. This approach simplifies coding so that you only need to provide the name of the table or procedure and provide a map of parameters matching the column names. This only works if the database provides adequate metadata. If the database doesn't provide this metadata, you will have to provide explicit configuration of the parameters.
RDBMS Objects including MappingSqlQuery, SqlUpdate and StoredProcedure requires you to create reusable and thread-safe objects during initialization of your data access layer. This approach is modeled after JDO Query wherein you define your query string, declare parameters, and compile the query. Once you do that, execute methods can be called multiple times with various parameter values passed in.
The Spring Framework's JDBC abstraction framework consists of four
different packages, namely
JdbcTemplate class and its various
callback interfaces, plus a variety of related classes. A subpackage
SimpleJdbcTemplate class and the related
SimpleJdbcCall classes. Another subpackage named
org.springframework.jdbc.core.namedparam contains the
NamedParameterJdbcTemplate class and the related
support classes. See Section 12.2, “Using the JDBC core classes to control basic JDBC processing and
error handling”, Section 12.4, “JDBC batch operations”, and Section 12.5, “Simplifying JDBC operations with the SimpleJdbc classes”
contains a utility class for easy
DataSource access, and various simple
DataSource implementations that can be
used for testing and running unmodified JDBC code outside of a Java EE
container. A subpackage named
support for creating in-memory database instances using Java database
engines such as HSQL and H2. See Section 12.3, “Controlling database connections” and
Section 12.8, “Embedded database support”
contains classes that represent RDBMS queries, updates, and stored
procedures as thread safe, reusable objects. See Section 12.6, “Modeling JDBC operations as Java objects”.This approach is modeled by JDO, although of
course objects returned by queries are “disconnected” from
the database. This higher level of JDBC abstraction depends on the
lower-level abstraction in the
org.springframework.jdbc.support package provides
SQLException translation functionality and some
utility classes. Exceptions thrown during JDBC processing are translated
to exceptions defined in the
package. This means that code using the Spring JDBC abstraction layer
does not need to implement JDBC or RDBMS-specific error handling. All
translated exceptions are unchecked, which gives you the option of
catching the exceptions from which you can recover while allowing other
exceptions to be propagated to the caller. See Section 12.2.4, “SQLExceptionTranslator”.