第 12 章 使用ORM工具进行数据访问 - Spring Framework reference 2.0.5 参考手册中文版

测试简单。 Spring的IoC使得替换不同的实现和配置变得非常简单， 这些内容包括：Hibernate SessionFactory 的位置，JDBC DataSource， 事务管理器以及映射对象的实现（如果需要）等。这样也就很容易隔离并测试持久化相关的代码的各个部分。

异常封装。 Spring能够封装你所选择的O/R Mapping工具所抛出的异常， 将它们从专有的、潜在的checked exception转化为一组抽象的runtime DataAccessException体系。 这可以使你仅需要在恰当的应用程序层次去处理大部分不可恢复的持久层异常，从而避免了很多令人讨厌的catch/throw以及异常声明。 当然，你还是可以在你需要的地方捕捉和处理异常。回想一下JDBC异常（包括与DB相关的Dialect）被转变为同样的异常体系，这就意味着你可以在一致的编程模型中处理JDBC操作。

通用的资源管理。 Spring的application context能够处理诸如Hibernate的 SessionFactory， JDBC的 DataSource，iBatis的SQL Maps配置对象以及其他相关资源的定位和配置。 这样，这些配置的值很容易被管理和修改。Spring提供了简单、有效、安全的对持久层资源的处理。 以Hibernate为例，通常在使用Hibernate时，需要使用同一个Hibernate Session 对象以确保高效和恰当地事务处理。 Spring让我们能够很容易透明地创建并绑定一个 Session 到当前线程。 你可以使用以下两种办法之一：通过使用一个外部的template包装类在Java代码层次实现， 或者通过Hibernate的 SessionFactory 暴露当前 Session 对象（对于那些建立在Hibernate3原生的API上的DAO）。 这样，对于任何的事务环境（本地事务或者JTA），Spring解决了许多在Hibernate使用中不断出现的这样那样的问题。

综合的事务管理。 Spring允许你封装你的O/R Mapping代码， 这可以通过声明式的AOP方法拦截器或者在Java代码级别上使用一个外部的template包装类。 无论使用哪一种方式，事务控制都会帮助你做相关处理，例如万一有异常发生时的事务操作（rollback）。 正如我们下面要讨论的一样，你能够使用和替换各种事务管理器，却不会使你的Hibernate/JDO相关的代码受到影响。 例如，不管采用本地事务还是JTA，完整的Service层的代码（如声明式事务管理）在这种场景下都是相同的。 作为一个附加的功能，JDBC相关的代码能够在事务级别上与你所使用的O/R映射代码无缝整合。 这一功能对于那些诸如批量处理、BLOB的操作等并不适合采用O/R Mapping操作的，但是需要与O/R Mapping操作一起参与相同的事务来说是相当有用的。

避免绑定特定技术允许mix-and-match的实现策略。 虽然Hibernate非常强大、灵活、开源而且免费，但它还是使用了自己的特定的API。 此外，有人也许会争辩：iBatis更轻便而且在不需要复杂的O/R映射策略的应用中使用时能够表现得非常优秀。 如果可以选择的话，使用标准或抽象的API来实现主要的应用需求通常是更好的，尤其是当你可能会因为功能、性能或其他方面的原因而需要切换到另一种实现的时候。 举例来说，Spring对Hibernate事务和异常抽象，允许你通过IoC机制轻松封装mapper和DAO对象来实现数据访问功能，这些特性都能够使你在 不牺牲Hibernate强大功能 的情况下在你的应用程序中隔离Hibernate的相关代码。 处理DAO的高层次的service代码无需知道DAO的具体实现。这一机制可以很容易使用mix-and-match方案互不干扰地实现数据访问层（比如在一些地方用Hibernate，一些地方使用JDBC，其他地方使用iBatis）， mix-and-match的特性也有利于处理遗留代码并在各种技术（JDBC、Hibernate和iBatis）之间取长补短.