Spring中文指南离线版本.docx

Spring中文指南离线版本.docx

《Spring中文指南离线版本.docx》由会员分享，可在线阅读，更多相关《Spring中文指南离线版本.docx（17页珍藏版）》请在冰豆网上搜索。

Spring中文指南离线版本

1第十一章-使用ORM工具进行数据访问

1.1简介

Spring在资源管理，DAO实现支持以及实物策略等方面提供了与Hibernate, JDO和iBATIS SQL映射的集成。

 对Hibernate，Spring使用了很多IoC的方便的特性提供了一流的支持，帮助你处理很多典型的Hibernate整合的问题。

所有的这些都遵守Spring通用的事务和DAO异常体系。

当您选择使用O/R映射来创建数据访问应用程序的时候，Spring的增加部分就会向您提供重要的支持。

首先你应该了解的是，一旦你使用了Spring对O/R映射的支持，你不需要亲自作所有的事情。

在决定花费力气，冒着风险建造类似的内部底层结构之前，我们都建议您考虑和利用Spring的解决方案。

不管你使用的是何种技术，大部分的O/R映射支持都可以以library样式被使用，因为所有的东西都是被设计成一组可重复利用的JavaBeans。

在ApplicationContext和BeanFactory中使用更是提供了配置和部署简单的好处，因此，这一章里的大多数例子都是在ApplicationContext中配置。

使用Spring构建你的ORM应用的好处包括：

✧避免绑定特殊的技术，允许mix-and-match的实现策略

虽然Hibernate非常强大，灵活，开源而且免费，但它还是使用了自己的特定的API。

此外有人也许会争辩：

iBatis更轻便而且在不需要复杂的O/R映射策略的应用中使用也很优秀。

能够选择的话，使用标准或抽象的API来实现主要的应用需求，通常是更好的。

尤其，当你可能会因为功能，性能或其他方面的原因而需要切换到另一个实现的时候。

举例来说，Spring对Hibernate事务和异常的抽象，以及能够让你轻松交换mapper和DAO对象（实现数据访问功能）的IoC机制，这两个特性可以让你在不牺牲Hibernate性能的情况下，在你的应用程序中隔离Hibernate的相关代码。

处理DAO的高层次的service代码不需要知道DAO的具体实现。

这个方法可以很容易使用mix-and-match方案互不干扰地实现数据访问层（比如在一些地方用Hibernate，一些地方使用JDBC，其他地方使用iBatis），mix-and-match有利于处理遗留下来的代码以及利用各种技术（JDBC,Hibernate,iBatis）的长处。

✧测试简单

Spring的IoC使得很容易替换掉不同的实现，Hibernate SessionFacotory的位置，datasource, 事务管理, 映射对象的实现。

这样就很容易隔离测试持久化相关代码的各个部分。

✧普通的资源管理

Spring的application context能够处理诸如Hibernate 的SessionFactory， JDBC的datasource，iBatis的SQLMaps配置对象以及其他相关资源的定位和配置。

这使得这些配置的值很容易被管理和修改。

Spring提供了有效，简单和安全的Hibernate Session处理。

一般的使用Hibernate的代码则需要使用同一个Hibernate Session对象以确保有效和恰当地事务处理。

而Spring让我们可以很容易透明地创建和绑定一个session到当前线程；你可以使用以下两种办法之一：

声明式的AOP方法拦截器，或通过使用一个外部的template包装类在Java代码层次实现。

这样，Spring就解决了在很多Hibernate论坛上出现的使用问题。

✧异常包装

Spring能够包装Hibernate异常，把它们从专有的，checked exception变为一组抽象的runtime exception。

这样你就可以仅仅在恰当的层处理大部分的不可恢复的异常，使你避免了很多讨厌的catch/throw以及异常声明。

你还是可以在你需要的地方捕捉和处理异常。

回想一下JDBC异常（包括与DB相关的方言）被转变为同样的异常体系，这就意味着你可以在一致的编程模型中处理JDBC操作。

✧综合的事务管理

Spring允许你包装你的ORM代码，通过使用声明式的AOP方法拦截器或者在代码级别使用外部的template包装类。

不管使用哪一种，事务相关的语义都会为你处理，万一有异常发生也会帮你做适当的事务操作（比如rollback）。

就象我们下面要讨论的一样，你能够使用和替换各种transaction managers，却不会使你的Hibernate相关的代码受到影响。

更好的是，JDBC相关的代码可以完全和Hibernate代码integrate transactionaly。

这对于处理那些没有用Hibernate或iBatis实现的功能非常有用。

1.2Hibernate

1.2.1资源管理

典型的应用经常会被重复的资源管理代码搞胡乱。

很多项目尝试创造自己的方案解决这个问题，有时会为了编程方便牺牲适当的故障处理。

对于恰当的资源处理Spring提倡令人瞩目的简单的解决方案：

使用templating的IoC，比如基础的class和回调接口，或者提供AOP拦截器。

基础的类负责固定的资源处理，以及将特定的异常转换为unchecked异常体系。

Spring引进了DAO异常体系，可适用于任何数据访问策略。

对于直接使用JDBC的情况，前面章节提到的JdbcTemplate类负责处理connection，正确地把SQLExeption变为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（使用业务对象）等等。

1.2.2在application context中定义资源

为了避免将应用对象贴紧硬编码的资源lookup，Spring允许你像定义普通bean一样在application context中定义诸如JDBC DataSource，Hibernate SessionFactory的资源。

需要访问这些资源的应用对象只需要持有这些预定义实例的引用。

下面的代码演示如何创建一个JDBC DataSource和Hibernate SessionFactory：

class="org.springframework.jndi.JndiObjectFactoryBean">

java:

comp/env/jdbc/myds

class="org.springframework.orm.hibernate.LocalSessionFactoryBean">

product.hbm.xml

net.sf.hibernate.dialect.MySQLDialect

……

你可以将一个JNDI定位的DataSource换为一个本地定义的如DBCP的BasicDataSource，如下面的代码：

destroy-method="close">

    org.hsqldb.jdbcDriver

    jdbc:

hsqldb:

hsql:

//localhost:

9001

    sa

当然你也可以把本地的SessionFactory换为JNDI定位的，但是如果不是在EJB上下文中，这是不需要的。

（查看“容器资源 vs 本地资源”一节）

1.2.3反转控制：

Template和Callback

对于可以成为定制的数据访问对象或业务对象的方法来说，基本的模板编程模型看起来像下面所示的代码那样。

对于外部对象没有任何实现特定接口的要求，它只需要提供一个Hibernate的SessionFacotry。

它可以从任何地方得到，比较适宜的方法是作为从Spring 的application context中得到的bean引用：

通过简单的setSessionFactory这个bean属性setter。

下面的代码显示了在application context中一个DAO的定义，它引用了上面定义的SessionFactory，同时展示了一个DAO方法的具体实现。

….

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）;

              //对结果list做一些处理

              return result;

            }

          }

        ）;

    }

}

一个callback的实现能在任何的Hibernate数据访问中有效使用。

HibernateTemplate会确保Sessions正确的打开和关闭，并且会自动参与事务。

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）;

    }

}

1.2.4应用AOP拦截器（Interceptor）代替Template

Spring的AOP  HibernateInterceptor是作为HibernateTemplate的替换，它在一个委托的try/catch块中直接写Hibernate代码，以及在application context中的一个interceptor定义，从而代替callback的实现。

下面演示了在application context中DAO，interceptor以及proxy定义，同时还有一个DAO方法的具体实现：

    class=”org.springframework.orm.hibernate.HibernateInterceptor”>

class=”org.springframework.aop.framework.ProxyFactoryBean”>

      product.ProductDao

        myHibernateInterceptor

        myProductDaoTarget

……

public class ProductDaoImpl extends HibernateDaoSupport implements ProdctDao {

    public List loadProdctsByCategory（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 就肯定会自动参与进来。

HibernateaTemplate在内部使用SessionFactoryUtils，他们是一样的底层结构。

HibernateInterceptor最主要的优点是允许在数据访问代码中抛出checked应用异常，而HibernateTemplate在回调中严格限制只能抛出unchecked exception。

值得注意的是我们可以把各种check以及抛出应用异常推迟到回调之后。

Interceptor的主要缺点是它需要在context进行特殊的装配。

HibernateTemplate的简便方法在很多场景下更简单些。

11.2.5．编程式的事务划分

在这些低层次的数据访问服务之上，可以在应用的高层次上划分事务，让事务横跨多个操作。

这里对于相关的业务对象（BO）同样没有实现接口的限制，它只需要一个Spring的PlatformTransactionManager。

同SessionFactory一样，这个manager可以来自任何地方，但是最好是作为一个经由setTransactionManager方法设置的bean引用。

下面演示了在Srping application context中一个transaction manager和一个业务对象的定义，以及具体的业务方法是如何实现的：

  ……

class=”org.springframework.orm.hibernate.HibernateTransactionManager”>

public class ProductServiceImpl implements ProductService {

    private PlatformTransactionManager transactionManager;

    private ProductDao productDao;

    //上面两个的setter方法

    public void increasePriceOfAllProductsInCategory（final String category） {

        TransactionTemplate transactionTemplate = 

new TransactionTemplate（this.transactionManager）;

        transactionTemplate.setPropagationBehavior（

TransactionDefinition.PROPAGATION_REQUIRED）;

        transactionTemplate.execute（

            new TransactionCallbackWithoutResult（） {

              publi