资源管理
典型的应用经常会被重复的资源管理代码搞胡乱。 很多项目尝试创造自己的方案解决这个问题，有时会为了编程方便牺牲适当的故障处理。 对于恰当的资源处理Spring提倡令人瞩目的简单的解决方案：使用templating的IoC， 比如基础的class和回调接口，或者提供AOP拦截器。基础的类负责固定的资源处理， 以及将特定的异常转换为unchecked异常体系。Spring引进了DAO异常体系，可适用于任何数据访问策略。 对于直接使用JDBC的情况，前面章节提到的JdbcTemplate类负责处理connection， 正确地把SQLException 变为DataAccessException 体系（包括将与数据库相关的SQL错误代码变成有意义的异常类）。 它同时支持JTA和JDBC事务，通过它们各自的Spring transaction managers。 Spring同样也提供了对Hibernate和JDO的支持：一个HibernateTemplate/JdoTemplate类似于 JdbcTemplate，HibernateInterceptor/JdoInterceptor，以及一个Hibernate/JDO transaction manager。主要的目的是：能够清晰地划分应用层次而不管使用何种数据访问和事务技术；使应用对象之间的耦合松散。业务对象（BO）不再依赖于数据访问和事务策略；不再有硬编码的资源lookup；不再有难于替换的singletons ；不再有自定义的服务注册。一个简单且坚固的方案连接了应用对象，并且使它们可重用尽可能地不依赖容器。虽然所有的数据访问技术都能独立使用，但是与Spring application context结合更好一些，它提供了基于xml的配置和普通的与Spring 无关的JavaBean实例。在典型的Spring app中，很多重要的对象都是JavaBeans：数据访问template，数据访问对象（使用template）,transaction managers, 业务对象（使用数据访问对象和transaction managers），web view resolvers, web controller（使用业务对象）等等。
在 Application Context中的Bean 声明
为了避免将应用对象贴紧硬编码的资源lookup， Spring允许你像定义普通bean一样在application context中定义诸如 JDBC DataSource，Hibernate SessionFactory 的资源。 需要访问这些资源的应用对象只需要持有这些预定义实例的引用。 下面的代码演示如何创建一个JDBC DataSource和Hibernate SessionFactory ：
<beans> <bean id="myDataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/myds</value> </property> </bean> <bean id="mySessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> <property name="mappingResources"> <list> <value>product.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">net.sf.hibernate.dialect.MySQLDialect</prop> </props> </property> <property name="dataSource"> <ref bean="myDataSource"/> </property> </bean> ... </beans> 你可以将一个JNDI定位的DataSource换为一个本地定义的如DBCP的BasicDataSource，如下面的代码： : <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName"> <value>org.hsqldb.jdbcDriver</value> </property> <property name="url"> <value>jdbc:hsqldb:hsql://localhost:9001</value> </property> <property name="username"> <value>sa</value> </property> <property name="password"> <value></value> </property> </bean>
当然你也可以把本地的SessionFactory换为JNDI定位的， 但是如果不是在EJB上下文中，这是不需要的。（查看“容器资源 vs 本地资源”一节）
.反向控制: 模板和回调的使用
对于可以成为定制的数据访问对象或业务对象的方法来说， 基本的模板编程模型看起来像下面所示的代码那样。 对于外部对象没有任何实现特定接口的要求，它只需要提供一个Hibernate的SessionFactory。 它可以从任何地方得到，比较适宜的方法是作为从Spring 的application context中得到的bean引用： 通过简单的setSessionFactory这个bean属性setter。下面的代码显示了在application context中一个DAO的定义， 它引用了上面定义的SessionFactory，同时展示了一个DAO方法的具体实现。
<beans> <bean id="myProductDao" class="product.ProductDaoImpl"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> ... </beans> public class ProductDaoImpl implements ProductDao { private SessionFactory sessionFactory; public void setSessionFactory(SessionFactory sessionFactory) { this.sessionFactory = sessionFactory; } public List loadProductsByCategory(final String category) { HibernateTemplate hibernateTemplate = new HibernateTemplate(this.sessionFactory); return (List) hibernateTemplate.execute( new HibernateCallback() { public Object doInHibernate(Session session) throws HibernateException { List result = session.find( "from test.Product product where product.category=?", category, Hibernate.STRING); // do some further stuff with the result list return result; } } ); } }
一个callback的实现能在任何的Hibernate数据访问中有效使用。 HibernateTemplate会确保Session正确的打开和关闭，并且会自动参与事务。 Template实例是线程安全的，可重用的，因此可以作为外部类的实例变量而被保持。 对于简单的一步操作，例如简单的find,load, saveOrUpdate,或者delete调用， HibernateTemplate提供了可选的简单方法可以用来替换这种一行的callback实现。 此外，Spring提供了一个简便的HibernateDaoSupport基类， 这个基类提供了setSessionFactory方法来接受一个SessionFactory，getSessionFactory 以及getHibernateTemplate方法是子类使用的。这样对于典型的需求就可以有很简单的DAO实现：
public class ProductDaoImpl extends HibernateDaoSupport implements ProductDao { public List loadProductsByCategory(String category) { return getHibernateTemplate().find( "from test.Product product where product.category=?", category, Hibernate.STRING); } }
利用AOP拦截器(Interceptor)取代Template
Spring的AOP HibernateInterceptor是作为HibernateTemplate的替换， 它在一个委托的try/catch块中直接写Hibernate代码， 以及在application context中的一个interceptor定义，从而代替callback的实现。 下面演示了在application context中DAO，interceptor以及proxy定义，同时还有一个DAO方法的具体实现：
<beans> ... <bean id="myHibernateInterceptor" class="org.springframework.orm.hibernate.HibernateInterceptor"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> <bean id="myProductDaoTarget" class="product.ProductDaoImpl"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> <bean id="myProductDao" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyInterfaces"> <value>product.ProductDao</value> </property> <property name="interceptorNames"> <list> <value>myHibernateInterceptor</value> <value>myProductDaoTarget</value> </list> </property> </bean> ... </beans> public class ProductDaoImpl extends HibernateDaoSupport implements ProductDao { public List loadProductsByCategory(final String category) throws MyException { Session session = SessionFactoryUtils.getSession(getSessionFactory(), false); try { List result = session.find( "from test.Product product where product.category=?", category, Hibernate.STRING); if (result == null) { throw new MyException("invalid search result"); } return result; } catch (HibernateException ex) { throw SessionFactoryUtils.convertHibernateAccessException(ex); } } }
这个方法必须要有一个HibernateInterceptor才能工作。 getSession方法中的”false”标志为了确保Session已经存在， 否则SessionFactoryUtils会创建一个新的。 如果线程中已经存在一个 SessionHolder比如一个HibernateTransactionManager事务 ，那SessionFactoryUtils 就肯定会自动参与进来。HibernateTemplate 在内部使用SessionFactoryUtils， 他们是一样的底层结构。 HibernateInterceptor最主要的优点是允许在数据访问代码中抛出checked应用异常， 而HibernateTemplate在回调中严格限制只能抛出未检查异常。 值得注意的是我们可以把各种check以及抛出应用异常推迟到回调之后。 Interceptor的主要缺点是它需要在context进行特殊的装配。HibernateTemplate的简便方法在很多场景下更简单些
编程式的事务划分
在这些低层次的数据访问服务之上，可以在应用的高层次上划分事务， 让事务横跨多个操作。这里对于相关的业务对象(BO)同样没有实现接口的限制， 它只需要一个Spring的PlatformTransactionManager。同SessionFactory一样， 这个manager可以来自任何地方， 但是最好是作为一个经由setTransactionManager 方法设置的bean引用， 例如,用setProductDao方法来设置productDAO. 下面演示了在Srping application context中一个transaction manager和一个业务对象的定义， 以及具体的业务方法是如何实现的：
<beans> ... <bean id="myTransactionManager" class="org.springframework.orm.hibernate.HibernateTransactionManager"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> <bean id="myProductService" class="product.ProductServiceImpl"> <property name="transactionManager"> <ref bean="myTransactionManager"/> </property> <property name="productDao"> <ref bean="myProductDao"/> </property> </bean> </beans> public class ProductServiceImpl implements ProductService { private PlatformTransactionManager transactionManager; private ProductDao productDao; public void setTransactionManager(PlatformTransactionManager transactionManager) { this.transactionManager = transactionManager; } public void setProductDao(ProductDao productDao) { this.productDao = productDao; } public void increasePriceOfAllProductsInCategory(final String category) { TransactionTemplate transactionTemplate = new TransactionTemplate(this.transactionManager); transactionTemplate.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); transactionTemplate.execute( new TransactionCallbackWithoutResult() { public void doInTransactionWithoutResult(TransactionStatus status) { List productsToChange = productDAO.loadProductsByCategory(category); ... } } ); } }
声明式的事务划分
作为可选的，我们可以使用Spring的AOP TransactionInterceptor来替换事务划分的手工代码， 这需要在application context中定义interceptor。 这个方案使得你可以把业务对象从每个业务方法中重复的事务划分代码中解放出来。 此外，像传播行为和隔离级别等事务概念能够在配置文件中改变，而不会影响业务对象的实现。
<beans> ... <bean id="myTransactionManager" class="org.springframework.orm.hibernate.HibernateTransactionManager"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> <bean id="myTransactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor"> <property name="transactionManager"> <ref bean="myTransactionManager"/> </property> <property name="transactionAttributeSource"> <value> product.ProductService.increasePrice*=PROPAGATION_REQUIRED product.ProductService.someOtherBusinessMethod=PROPAGATION_MANDATORY </value> </property> </bean> <bean id="myProductServiceTarget" class="product.ProductServiceImpl"> <property name="productDao"> <ref bean="myProductDao"/> </property> </bean> <bean id="myProductService" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyInterfaces"> <value>product.ProductService</value> </property> <property name="interceptorNames"> <list> <value>myTransactionInterceptor</value> <value>myProductServiceTarget</value> </list> </property> </bean> </beans> public class ProductServiceImpl implements ProductService { private ProductDao productDao; public void setProductDao(ProductDao productDao) { this.productDao = productDao; } public void increasePriceOfAllProductsInCategory(final String category) { List productsToChange = this.productDAO.loadProductsByCategory(category); ... } ... }
同HibernateInterceptor一样，TransactionInterceptor 允许任何checked的应用异常在callback代码中抛出， 而TransactionTemplate 在callback中严格要求unchecked异常。 TransactionTemplate 会在一个unchecked异常抛出时触发一个rollback， 或者当事务被应用程序通过TransactionStatus标记为rollback-only。 TransactionInterceptor默认进行同样的操作，但是它允许对每个方法配置rollback方针。 一个简便可选的创建声明式事务的方法是：TransactionProxyFactoryBean， 特别是在没有其他AOP interceptor牵扯到的情况下。对一个特定的目标bean， TransactionProxyFactoryBean用事务配置自己联合proxy定义。 这样就把配置工作减少为配置一个目标bean以及一个 proxy bean的定义（少了interceptor的定义）。 此外你也不需要指定事务方法定义在哪一个接口或类中。
<beans> ... <bean id="myTransactionManager" class="org.springframework.orm.hibernate.HibernateTransactionManager"> <property name="sessionFactory"> <ref bean="mySessionFactory"/> </property> </bean> <bean id="myProductServiceTarget" class="product.ProductServiceImpl"> <property name="productDao"> <ref bean="myProductDao"/> </property> </bean> <bean id="myProductService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"> <ref bean="myTransactionManager"/> </property> <property name="target"> <ref bean="myProductServiceTarget"/> </property> <property name="transactionAttributes"> <props> <prop key="increasePrice*">PROPAGATION_REQUIRED</prop> <prop key="someOtherBusinessMethod">PROPAGATION_MANDATORY</prop> </props> </property> </bean> </beans>
事务管理策略
TransactionTemplate 和TransactionInterceptor 都是将真正的事务处理代理给一个PlatformTransactionManager实例， 比如在Hibernate应用中它可以是一个HibernateTransactionManager （对于单独一个的Hibernat SessionFactory， 实质上使用一个ThreadLocal的Session）或一个JtaTransactionManager （代理给容器的JTA子系统）。 你甚至可以使用自定义的PlatformTransactionManager的实现。 所以呢，如果你的应用需要分布式事务的时候， 将原来的Hibernate事务管理转变为JTA之类的，只不过是改变配置文件的事情。 简单地，将Hibernate transaction manager替换为Spring的JTA transaction实现。 事务的划分和数据访问代码则不需要改变，因为他们使用的是通用的事务管理API。 对于横跨多个Hibernate SessionFacotry的分布式事务， 只需简单地将JtaTransactionManager 同多个LocalSessionFactoryBean 定义结合起来作为一个事务策略。 你的每一个DAO通过bean属性得到各自的SessionFactory引用。 如果所有的底层JDBC datasource都是支持事务的容器， 那么只要一个业务对象使用了 JtaTransactionManager策略， 它就可以横跨多个DAO和多个session factories来划分事务，而不需要特殊的对待.
<beans> <bean id="myDataSource1" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/myds1</value> </property> </bean> <bean id="myDataSource2" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"> <value>java:comp/env/jdbc/myds2</value> </property> </bean> <bean id="mySessionFactory1" class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> <property name="mappingResources"> <list> <value>product.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">net.sf.hibernate.dialect.MySQLDialect</prop> </props> </property> <property name="dataSource"> <ref bean="myDataSource1"/> </property> </bean> <bean id="mySessionFactory2" class="org.springframework.orm.hibernate.LocalSessionFactoryBean"> <property name="mappingResources"> <list> <value>inventory.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">net.sf.hibernate.dialect.OracleDialect</prop> </props> </property> <property name="dataSource"> <ref bean="myDataSource2"/> </property> </bean> <bean id="myTransactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/> <bean id="myProductDao" class="product.ProductDaoImpl"> <property name="sessionFactory"> <ref bean="mySessionFactory1"/> </property> </bean> <bean id="myInventoryDao" class="product.InventoryDaoImpl"> <property name="sessionFactory"> <ref bean="mySessionFactory2"/> </property> </bean> <bean id="myProductServiceTarget" class="product.ProductServiceImpl"> <property name="productDao"> <ref bean="myProductDao"/> </property> <property name="inventoryDao"> <ref bean="myInventoryDao"/> </property> </bean> <bean id="myProductService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <property name="transactionManager"> <ref bean="myTransactionManager"/> </property> <property name="target"> <ref bean="myProductServiceTarget"/> </property> <property name="transactionAttributes"> <props> <prop key="increasePrice*">PROPAGATION_REQUIRED</prop> <prop key="someOtherBusinessMethod">PROPAGATION_MANDATORY</prop> </props> </property> </bean> </beans>
HibernateTransactionManager 和JtaTransactionManager 都使用了与容器无关的Hibernate事务管理器的lookup或JCA连接器（只要事务不是用EJB发起的）， 从而考虑到在适当JVM级别上的cache处理。 而且HibernateTransactionManager 能够为普通的JDBC访问代码输出JDBC Connection。 这就可以使得混合的Hibernate/JDBC数据访问可以不用JTA而在高层次上进行事务划分， 只要它们使用的是同一个数据库!
注释, 对于使用TransactionProxyFactoryBean 声明性划分事务属于可选方式,请参考for an alternative approach to using 第 “BeanNameAutoProxyCreator，另一种声明方式”.
使用Spring管理的应用Bean
一个Spring application context的定义能够被很多种不同的上下文实现所读取， 比如FileSystemXmlApplicationContext 和 ClassPathXmlApplicationContext以及XmlWebApplicationContext。 默认的情况下，一个web应用程序会从”WEB-INF/applicationContext.xml”中得到root context。 在所有的Spring应用中，XML文件中定义的application context会把所有相关的application beans连接起来， 包括Hibernate session factory以及数据访问和业务对象（就像上面定义的那些bean）。 它们中的大部分都不会意识到被Spring容器所管理，甚至在同其他bean合作的时候， 因为它们仅仅遵循JavaBeans的规范。一个bean属性及可以表示值参数，也可以是其他的合作bean。 下面的bean定义能够作为Spring web MVC context的一部分，在最基础的 application context中访问business beans。
<bean id="myProductList" class="product.ProductListController"> <property name="productService"> <ref bean="myProductService"/> </property> </bean>
Spring web controller所需要的所有业务或数据访问对象都是通过bean引用提供的， 所以在应用得上下文中就不再需要手动的bean lookup了。但是在与Struts一起使用， 或在一个EJB实现中甚至一个applet中使用，你仍然可以自己手动地look up一个bean （意思大概是Spring不会影响你原来的使用方式）。因此，Spring beans事实上能够在任何地方支持。 你只需要一个application context的引用，你可以在一个web 应用中通过一个servlet context的属性得到， 或者手动地从一个文件或class path resource创建实例。
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(servletContext); ProductService productService = (ProductService) context.getBean("myProductService"); ApplicationContext context = new FileSystemXmlApplicationContext("C:/myContext.xml"); ProductService productService = (ProductService) context.getBean("myProductService"); ApplicationContext context = new ClassPathXmlApplicationContext("myContext.xml"); ProductService productService = (ProductService) context.getBean("myProductService");
容器资源 vs 本地资源
Spring的资源管理考虑到了在JNDI SessionFactory和local的SessionFactory之间的简单切换， 对于JNDI DataSource也是这样的，不需要修改一行代码。 把资源定义放在容器中还是放在应用程序本地中主要是由使用的事务策略决定的。 同Spring定义的本地SessionFactory相比，一个手动注册的JNDI SessionFactory并不会提供任何多余的好处。 如果通过Hibernate的JCA连接器进行注册，对于参与JTA事务有明显的好处， 尤其在EJB中。而Spring的transaction支持的一个重要好处就是不依赖于任何一个容器。 使用非JTA的策略配置，程序将会在独立的或测试的环境下同样正常工作。尤其在典型的单数据库事务情况下， 这将是JTA的轻便和强大的替换方案。当使用一个本地的EJB SLSB来驱动事务时， 尽管你可能只访问一个数据库而且仅仅通过CMT使用SLSBs的声明性事务，你仍然要依赖于EJB容器和JTA。 编程式使用JTA的替换方案依然需要J2EE环境。JTA不仅仅在自己这一方面而且在JNDI DataSource方面， 引入了容器依赖。对于非Spring的，JTA驱动的Hibernate事务，为了在适当的JVM层次上做caching， 你必须使用Hibernate JCA连接器或者额外的Hibernate事务代码及配置好的JTA事务。 Spring驱动的事务能够很好地使用本地定义的Hibernate SessionFacotry工作，就像使用本地的JDBC DataSource工作（ 当然访问的必须是一个单独的数据库）。因此你只需要在面对分布式事务需求的时候退回到Spring的JTA事务策略。 必须要注意，一个JCA连接器需要特定容器的部署步骤，而且首先要支持JCA。 这要比使用本地资源定义和Spring驱动事务来部署一个简单的Web应用麻烦多了。 而且你通常需要企业版本的容器，比如WebLogic的Express版本并不提供JCA。 一个仅使用本地资源并且事务仅跨越一个数据库的Spring应用将会在任何一种J2EE Web容器中工作 （不需要JTA,JCA或者EJB），比如Tomcat,Resin, 甚至普通的Jetty。 更多的是，这样的中间层可以在桌面应用或测试用例中简单地重用。综上所述：如果你不使用EJB， 坚持使用本地SessionFactory的创建和Spring的HibernateTransactionManager 或JtaTransactionManager。 你可得到包括适当的JVM层次上的caching以及分布式事务在内的所有好处，却不会有任何容器部署的麻烦。 通过JCA连接器的Hibernate SessionFactory 的JNDI注册仅仅在EJB中使用会带来好处。
举例
Spring发行包中的Petclinic这个例子提供了可选的DAO实现和application context配置文件 （分别针对Hibernaet, JDBC, 和Apache OJB）。因此Petclinic可以作为可工作的示例应用， 阐明了在Spring web应用中如何使用Hibernate。它也利用了不同事务策略下的声明式事务划分。
