编写一个小框架来解决这一问题会非常容易。我相信大家也都曾这样做过，但为何不让Spring帮我们处理这一问题呢？我不敢保证我能想出一个更整洁、更优雅的解决方案。我们来看Spring框架是如何处理这种样板JDBC场景的。
Spring支持各种各样的JDBC、Hibernate、JDO和iBatis模板。模板采用样板概念，并将它转换为合法的编程术语。例如，下面的代码片断封装了上面列出的各个步骤：
DataSource ds = (DataSource) bf.getBean("myDataSource");
JdbcTemplate temp = new JdbcTemplate(ds);
List sensorList = temp.query("select sensor.type FROM sensors",
new RowMapper() {
public Object mapRow(ResultSet rs, int rowNum) throws SQLException;
return rs.getString(1);
}
});
这段简短的代码消除了JDBC编程的冗长，代表了前面提及的样板的思路。请注意我们使用了Spring的IoC来查找该查询的数据源。Spring还支持对已检查异常使用未检查异常；因此许多已检查的JDBC异常会重新映射到通常更有用而且更友好的未检查异常层次结构中。在Spring的上下文文件中配置该数据源类似于下面代码：
＜bean id="myDataSource"
class="org.apache.commons.dbcp.BasicDataSource"＞
＜property name="driverClassName"＞
＜value＞org.gjt.mm.mysql.Driver＜/value＞
＜/property＞
＜property name="url"＞
＜value＞jdbc:mysql://romulus/sensors＜/value＞
＜/property＞
＜property name="username"＞
＜value＞heater＜/value＞
＜/property＞
＜property name="password"＞
＜value＞hotshot＜/value＞
＜/property＞
＜/bean＞
在本例中，我们利用Apache commons工具箱配置了一个基本数据源。但并不是说我们只能使用它。我们可以改变配置，使用在JNDI中配置并装载的数据源。Spring提供了一些实用工具和IoC功能以配置和返回存储在JNDI中的对象。例如，若想配置并使用与JNDI上下文关联的数据源，则可以输入以下代码，替换先前的数据源配置：
＜bean id="myDataSource"
class="org.springframework.jndi.
JndiObjectFactoryBean"＞
＜property name="tempSensorDS"＞
＜value＞ConnectionFactory＜/value＞
＜/property＞
＜/bean＞
该代码突出了Spring所提供的关于表格的测试灵活性。该代码可以在“容器内”运行（从JNDI查找数据源），经过细微的改动之后也可在“容器外”运行。
虽然模板化机制仅适用于某些特定场合，但我们可以泛化这一概念，将它应用于更广泛的场合。例如，一种将已检查异常转变为未检查异常、此外还可能为异常处理提供一些中间或统一的异常处理策略的机制将会很有帮助。我们还可以使用该机制将底层的基本异常“软化”得更合乎人意。我们可以将PacketFrameParityFaultException软化为CommunicationsUnreliableException。这个重新映射的较软的异常表示情况可能并不那么严重，重新请求也是可以的。
Spring已经具备了一种类似于包装EJB调用（在最后一节介绍）的机制，但遗憾的是它并不具备任何“通用”的东西，至少在异常软化意义上是这样的。但Spring的确有一个非常健壮的AOP（面向方面编程）框架，我们可以用它来逼近这种行为。下面是一个关于这种软化适用领域的（公认的）精心设计的例子。
