那么如果我们改变主意，想用普通Java对象来实现业务组件；或者可能在测试中，我们想用一个返回“固定(canned)”响应的已清除(stubbed)对象来替换重量级EJB，该怎么做呢？利用IoC和Spring，通过更改Spring上下文文件就可轻而易举地实现这些目标。我们只需使用更常规一点的东西（如我们在第一个Spring例子中所看到的）来替换EJB代理的连接即可：
＜bean id="myBizServiceRef"
class="yourco.project.biz.MyStubbedBizService"＞
＜/bean＞
请注意，我只更改了Spring框架所返回的内容的细节，没有更改bean id。最后的结果是业务对象的解决方案未变；它看上去和以前完全一样：
MyBizInterface myService =
bf.getBean("myBizServiceRef");
最大的区别显然是实现该业务接口的对象现在由一个普通Java对象（POJO）支持，并且只是该接口的一个已清除(stubbed)版本。这给单元测试或改变业务服务的特性带来了极大方便，而对客户端代码的影响很小。
使用Spring来标准化异常
Spring的一大贡献是“模板化”代码块。这在纯JDBC编程中表现得最为明显。我们都曾写过具有下述功能的代码：
• 创建一个数据库连接，可以的话从某个池创建。
• 构造一个查询字符串并提交。
• 迭代结果并将数据封送到域对象中。
• 处理不同阶段出现的大量异常。
• 确保记得编写finally代码块以关闭连接。
但是各处的这种代码往往都会或多或少地有点“样板化”。一般来说这是有害的，不仅因为不需要的代码会增加，还因为有些东西可能会遗漏，如非常重要的关闭连接，如果没有实现它，可能导致数据资源池的泄漏。
虽然我敢肯定我们都曾多次写过这类“样板”代码，但是将Spring方法和直接的JDBC实现对照来看，其结果将会有趣而又对比鲜明。“传统”的JDBC实现可能如下：
Connection con = null;
try
{
String url = "jdbc://blah.blah.blah;";
con = myDataSource().getConnection();
Statement stmt = con.createStatement();
String query = "SELECT TYPE FROM SENSORS";
ResultSet rs = stmt.executeQuery(query);
while(rs.next()){
String s = rs.getString("TYPE);
logger.debug(s + " " + n);
}
} catch(SQLException ex)
{
logger.error("SQL ERROR!",ex);
}
finally
{
con.close();
}
对于该方法要做一些说明。首先，它是有效的！该代码绝对不会出现任何错误。它会连接到数据库，并从‘SENSOR’表获取所需的数据。该方法的基本问题源于缺乏抽象化。在大型应用程序中，必须反复剪切和粘贴这段代码，或者至少会出现类似的其他情况。较大的问题在于它依赖于编程人员去做“该做的事”。我们都知道，不管数据库操作的结果是什么，都必须用finally语句来关闭该数据库。有时我们忘记做该做的事。我和所有人一样感到内疚！
