Spring Framework概述 (2)

实体关系映射(O/R mapping, ORM)集成

当然你经常需要使用实体关系映射，而不是使用关系型数据访问。你的整体应用程序框架也必须支持这个。因而Spring继承了Hibernate(版本2 和3)、JDO(版本1 和2)、TopLink和其他ORM产品。他的数据访问架构允许与任何底层数据访问技术集成。Spring和Hibernate是一个相当流行的组合。

为什么你要用一个ORM产品加上Spring，而不是直接使用它呢？Spring在以下方面增加了重要价值：

会话管理。Spring提供了对诸如Hibernate或Toplink 会话的有效、简单而且安全的处理。相关的单独使用ORM工具的代码通常需要使用同一个“Session”对象来达到有效且合的事务处理。Spring能使用一个声明性的AOP方法拦截器或使用显式的Java 代码级的“模板”封装类来透明创建一个会话并将其绑定到当前线程。因而Spring解决了许多影响ORM 技术用户的使用问题。
资源管理。Spring应用程序上下文能处理Hibernate SessionFactory、JDBC数据源和其他相关资源的定位和配置。这使得这些值易于管理和更改。
完整的事务管理。Spring允许你将你的ORM代码封装为一个声明性的AOP方法拦截器或者一个显式的Java 代码级的“模板”封装类。不管哪种情况，事务语义都为你处理了，并且在异常发生时也作了恰当的事务处理(回滚等)。正如我们后面讨论的，你也可以使用并切换不同事务管理器而不影响你的ORM相关代码，并从中获益。一个额外的好处是为了支持大多数ORM工具JDBC相关代码能完全事务性地与ORM代码集成。这对于处理ORM没有实现的功能时很有用。
如上所述的异常封装。Spring能封装来自ORM层的异常，将它们从私有(可能是经过检查的)异常转换为一组抽象的运行时异常。这允许你可以不用烦人的样板化的catch/throw和异常声明仍能在恰当的层中处理大多数不可恢复的持久化异常。你仍能在任何需要的地方捕获和处理异常。请记住JDBC异常(包括数据库特有方言)也被转换为相同层次，这意味着你能在一致的编程模型内用JDBC执行一些操作。
避免和厂商绑定。ORM解决方案有不同的性能和特性，没有能满足所有情况的完美解决方案。作为选择，你会发现某一个功能正好不匹配你用的ORM工具的一个实现。这让你意识到你的数据访问对象接口的特定工具实现对你的架构有影响。一旦你因为功能、性能或其他原因需要切换到另一个实现，现在使用了Spring让最终的切换变得更容易了。Spring对你ORM工具的事务和异常的抽象，和它的IoC方法一起让你在映射器/DAO 对象实现数据访问功能间轻松切换，简单地实现将ORM特有代码控制在你应用程序的一个范围里而不牺牲你ORM工具的能力。和Spring一起发布的宠物医院范例程序演示了Spring通过提供使用JDBC、Hibernate、TopLink和Apache OJB实现的不同持久层而带来的可移植性方面的价值。
简化测试。Spring的控制反转方法使得切换实现和诸如Hibernate会话工厂、数据源、事务管理器和映射器对象实现(如果需要)之类的资源位置变得简单了。这简化了隔离和每部分持久化相关代码的单独测试。
综上所述，Spring让混用数据存取过程更简单了。尽管ORM在很多案例里赢得了颇有价值的生产力，无论一些ORM厂商怎么宣称，ORM不是所有问题的解决方案。即使你混用各种持久化方法，即使你不用JTA，Spring仍能提供一致的架构和事务策略。

在ORM并不理想的地方，Spring的简化JDBC并不是唯一选择：iBATIS SQL Maps 提供的“映射语句”也值得一看。它在保持自动从查询结果中创建映射对象的同时提供了对SQL的高层控制。Spring集成了SQL Maps。Spring的宠物店范例程序演示了iBATIS集成。

事务管理

仅抽象一个数据访问API是不够的；我们还需要考虑事务管理。JTA是当然的解决方案，但直接使用它的API是很笨重的，因而许多J2EE 开发者曾觉得EJB CMT是事务管理的唯一明智的选择。Spring改变了这一点。

Spring提供了它自己的针对事务管理的抽象。Spring 使用它来提供：

通过一个类似JdbcTemplate的回调模板来实现可编程的事务管理，比起直接使用JTA容易许多。
类似EJB CMT的声明性事务管理，但不需要EJB容器。实际上，正如我们所见，Spring的声明性事务管理能力是EJB CMT语义上的超集，有些独特的重要的好处。
Spring的事务抽象的独特之处在于它不绑定于JTA或其他任何事务管理技术。Spring使用事务策略概念，这减弱了底层事务基础部分(例如JDBC)对应用程序代码的影响。

为什么你需要关心这个？JTA不是对所有事务管理问题的最好答案吗？如果你正在写一个只与一个数据库打交道的应用程序，你不需要JTA的复杂性。你不关心XA事务或两阶段提交。你甚至可以不需要一个提供这些东西的高端应用服务器。但另一方面，你不会愿意在和多个数据源打交道时重写你的代码。