Spring架构支持arm吗 spring支持的orm有哪些

admin2024-06-04  20

第15章 Spring对各种ORM的集成

  • Spring对Hibernate的集成
  • Spring对IBATIS的集成
  • Spring中对其他ORM方案的集成概述

Spring对当前各种流行的ORM解决方案的集成主要体现在以下几个万面。

  • 统一的资源管理方式。
  • 特定于ORM的数据访问异常到Spring统一异常体系的转译。
  • 统一的数据访问事务管理及控制方式。

以下内容将主要围绕Spring对Hibernate3和iBATIS 2这两种ORM方案的集成来进行讲述,最后会对其他ORM方案的集成做一定的概述,以便在你要使用这些ORM方案的时候,知道如何从Spring这里获得支持。

现在,就让我们开始这趟Spring中对各种ORM解决方案的集成之旅吧!

15.1 Spring对Hibernate的集成

在当今Java的各种ORM解决方案中,Hibernate凭借其先期的优势以及后期的持续跟进,无疑已经成为基于ORM进行数据访问的事实标准。

15.1.1 旧日“冬眠”时光

先从Hibernate参考文档所提供的Session管理工具类说起,先看一下下方代码清单的内容吧(摘自Hibernate2.1.8参考文档)!

public class HibernateUtil {
    private static Log log = Logractory.getLog(Hibernateutll.class);
    private static final SessionFactory sessionFactory;

    static {
        try {
            // Create the SessionFactory
            sessionFactory = new Configuration().configure().buildSessionFactory();
        } catch (Throwable ex) {
            log.error("Initial SessionFactory creation failed.", ex);
            throw new ExceptionInInitializerError(ex);
        }
    }

    public static final ThreadLocal session = new ThreadLocal();

    public static Session currentSession() throws HibernateException {
        Session s = (Session) session.get();
        // Open a new Session, if this Thread has none yet
        if (s == null) {
            s = sessionFactory.openSession();
            session.set(s);
        }
        return s;
    }

    public static void closeSession() throws HibernateException {
        Session s = (Session) session.get();
        session.set(null);
        if (s != null) {
            s.close();
        }
    }
}

HibernateUtil的作用是对Session的初始化,获取以及释放进行统一的管理。 坦诚地说,只从HibernateUtil本身来说,我们没有太多可以指摘的,但是,当大部分人都按照下方代码清单中示例代码的样子来使用HibernateUtil的时候,问题就比较容易出现了。

Session session = HibernateUtil.currentSession();
Transaction tx = session.beginTransaction();
Cat princess = new Cat();
princess.setName("Princess");
princess.setSex('F');
princess.setWeight(7.4f);
session.save(princess);
tx.commit();
HibernateUtil.closeSession();

仅关注这段使用代码好像没有什么不妥之处,可是,以同样的方式铺开到整个团队的开发中的话,就真的不妥了。

对于一个团队来说,工作的分配通常是按照功能模块划分的,而不是按照应用程序的分层划分的,这就意味着,每个开发人员通常要负责自己模块中每层的各种功能实现,具体点儿说就是,每个开发人员都需要负贵自己功能模块中的DAO以及Service层对象开发。

为了能够给每个开发人员开发DAO以及Service对象提供适度的“公共设施”,我们通常会将Hibernate的使用进行适当的封装,将公用的一些行为抽象到父类中定义,这样,我们就有了类似下方代码清单所示的DAO父类实现(忽略了异常处理和其他细节)。

public class AbstractHibernateDao {
    private Session session = null;
    private Transaction transaction = null;

    public AbstractHibernateDao() throws HibernateException {
        session = HibernateUtil.currentSession();
    }

    public Session getCurrentSession() {
        return this.session;
    }

    public Transaction beginTransaction() {
        return getCurrentSession().beginTransaction();
    }

    public void commit() {
        if (this.transaction != null) {
            this.transaction.commit();
        }
    }

    public void rollback() {
        if (this.transaction != null) {
            this.transaction.rollback();
        }
    }

    public void closeSession() {
        HibernateUtil.closeSession();
    }
}

开发人员要实现DAO,需要继承该AbstractHibernateDao,并在构造方法中调用父类的构造方法。这样一旦子类实例化完毕,即可获得相应的Session进行数据访问,如下方代码清单所示。

public class FooHibernateDao extends AbstractHibernateDao implements IBarDao {
    public FooHibernateDao() {
        super();
    }

    public void saveOperation(Object po) {
        getCurrentSession().save(po);
    }
  	...
}

因为事务控制通常在Service层,所以FooHibernateDao中没有过多涉及特定的事务API以及Session管理的代码。不过,在仔细看加入这些相关逻辑的Service实现类之后,就会发现以这种方式使用Hibernate会是一种多么糟糕的体验。下方代码清单给出的就是这样一个Service实现类。

public class FooService {
    private FooHibernateDao dao;

    public void someBusinessLogic() throws Exception {
        try {
            getDao().beginTransaction();
            Object mockPO = new Object();
            getDao().saveOperation(mockPO);
            getDao().commit();
        } catch (HibernateException e) {
            getDao().rollbck();
            throw e;
        } catch (Exception e) {
            getDao().rollbck();
            throw e;
        } finally {
            getDao().closeSession();
        }
    }
	  ...
  
    public FooHibernateDao getDao() {
      return dao;
    }
  
    public void setDao(FooHibernateDao dao) {
      this.dao = dao;
    }
}

如果只是一个类或一个方法,即使这样处理,只要谨慎一些,还是可以保证程序的正常运行的。可是,在团队中充斥着各色开发人员的时候,当编程规范不能得到严格执行的时候,这样的Hibernate使用方式以及类似结构的程序设计,对于整个团队来说都不是一件容易的事情。

要关注事务管理,同时也要关注资源(Session)的管理,还得适度进行异常的处理,也许每个开发人员都精明能千,但当所有这一切凑在一起的时候,就难免会有疏漏了。这其实也不难解释,以这样的实践方式来使用Hibermate为什么会时不时发生资源泄漏之类的事故了。

当然,以上示例只是抽象出来的,以分散的Hibernate API封装,来使用Hibernate进行数据访问的方式中的一种。实际上,只是同时关注数据访问中的多个方面,并且没有合适的封装方式来使用Hibernate。项目中类似于这样的代码应该并不少见,而这直接影响到软件产品的质量,这才是我们应该重点关注的。所以,我们应该寻求新的Hibernate实践,将开发人员从复杂的数据访问API的使用中解放出来,使其能够更加高效地工作,从而促进整个软件产品质量的提高。

15.1.2 “春天”里的“冬眠"

鉴于HibernateAPI的使用,在具体项目实践过程中,也存在类似于JDBC API使用中资源管理以及异常的处理之类的普遍问题。Spring在JdbcTemplate的成功理念下,对Hibernate的使用以相同的方式进行了封装,从而使得我们不用在资源管理以及异常处理方面投入过多的精力。

同时,Spring对所有的数据访问技术相关的事务管理,也通过AOP的形式剥离出去,进一步避免了过多的方面纠缠在一起的困境。

1. HibernateTemplate的登场

对于旧日的Hibernate操作的封装方式来说,没有能够对Session资源的管理,以及数据访问异常进行更为集中合理的处理。所以,Spring提供了HibernateTemplate对Hibernate的使用进行模板化封装,并且在模板方法内部统一进行数据访问异常的处理。

基于HibernateTemplate的Session资源管理

Session是使用Hibernate与关系数据库进行数据访问的“纽带”,所有的数据访问操作必须经由Session的支持才能完成。对于日常开发来说,我们应该更多关注的是如何使用Session进行数据访问,而至于Session的获取以及释放等资源管理问题,则应该尽可能从频繁的数据访问代码中解脱出去,以避免过多方面的纠缠。 过去的Hibernate使用方式,就是因为每个开发人员都需要同时关注Session资源的管理,以及具体的基于Session的数据访问逻辑,才会出现稍有不慎就出现资源泄漏的情况。

HibernateTemplate统一对Session的获取以及释放等管理逻辑进行封装,将Session管理尽量保持在一处进行。而对于不同的数据访问需求,HibernateTemplate提供了HibernateCallback回调接口,以便调用方可以根据各自的数据访问需求进行定制,完全不会限制Hibernate任何功能的发挥。

与JdbcTemplate的实现相似,HibernateTemplate所有的模板方法以一个主要的模板方法为中心,该方法通过HibernateCallback回调接口为调用方公开Session资源以进行数据访问。下方代码清单是这个主要的模板方法定义。

public Object execute(HibernateCallback action, boolean exposeNativeSession) throws DataAccessException {
    Assert.notNull(action, "Callback object must not be null");

    Session session = getSession();
    boolean existingTransaction = (!isAlwaysUseNewSession() &&
            (!isAllowCreate() || SessionFactoryUtils.isSessionTransactional(session,
                    getSessionFactory())));
    if (existingTransaction) {
        logger.debug("Found thread-bound Session for HibernateTemplate");
    }
    FlushMode previousFlushMode = null;
    try {
        previousFlushMode = applyFlushMode(session, existingTransaction);
        enableFilters(session);
        Session sessionToExpose = (exposeNativeSession ? session : createSessionProxy(session));
        Object result = action.doInHibernate(sessionToExpose);
        flushIfNecessary(session, existingTransaction);
        return result;
    } catch (HibernateException ex) {
        throw convertHibernateAccessException(ex);
    } catch (SQLException ex) {
        throw convertJdbcAccessException(ex);
    } catch (RuntimeException ex) {
        // Callback code threw application exception...
        throw ex;
    } finally {
        if (existingTransaction) {
            logger.debug("Not closing pre-bound Hibernate Session after HibernateTemplate");
            disableFilters(session);
            if (previousFlushMode != null) {
                session.setFlushMode(previousFlushMode);
            } else {
                // Never use deferred close for an explicitly new Session.
                if (isAlwaysUseNewSession()) {
                    SessionFactoryUtils.closeSession(session);
                } else {
                    SessionFactoryUtils.closeSessionOrRegisterDeferredClose(session, getSessionFactory());
                }
            }
        }
    }
}

因为该模板方法要处理的方面很多,所以,看起来比较复杂。不过,让我们先把事务管理相关的代码搁置一边,对该模板方法进行简化,这样就比较容易看出该模板方法的真面目了。简化后的核心模板方法定义见下方代码清单。

public Object execute(HibernateCallback action, boolean exposeNativeSession) throws DataAccessException {
    Assert.notNull(action, "Callback object must not be null");

    Session session = getSession();
    try {
        Object result = action.doInHibernate(sessionToExpose);
        return result;
    } catch (HibernateException ex) {
        throw convertHibernateAccessException(ex);
    } catch (SQLException ex) {
        throw convertJdbcAccessException(ex);
    } catch (RuntimeException ex) {
        // Callback code threw application exception...
        throw ex;
    } finally {
        closeSession(session);
    }
}

实际上,去除事务相关的代码,为Hibernate操作提供一个模板方法就这么简单,只要将Session资源的管理纳入一个模板方法,而不是让它任意的散落到代码各处,我们就可以在很大程度上避免Session资源泄漏的危险。

如果愿意,我们可以在这个主要模板方法的基础上,为HibernateTemplate添加更多的数据访问操作,所有之后添加的模板方法最终都通过该主要模板方法执行数据访问。当然,这部分工作Spring也已经为我们做了,基本上也不需要我们自己劳神。

特定于Hibernate的数据访问异常转译

在简化后的HibernateTemplate核心模板方法中,除了对Session资源管理的代码,还需要我们关注的就是数据访问异常的处理。

Hibermate3之前的Hibernate数据访问异常类型是checkedexception,自然而然地就会出现本章开头的一幕,客户端需要根据特定的数据访问方式,捕获并处理特定于数据访问技术的异常类型。Spring从开始对Hibernate2提供支持的时候,就提供了SessionFactoryUtils工具类,帮助实现从HibernateException到Spring统一异常体系的转译。

随着越来越多的开发人员对uncheckedexception在数据访问领域存在合理性的认同,Hibermate3之后的HibernateException也改为了uncheckedexception类型,但将uncheckedexception的HibernateException转译到Spring的异常体系依然是值得做的一件事情。

SessionFactoryUtils类提供了convertHibernateAccessException静态方法进行HibernateException到Spring异常体系的转译(如下):

public static DataAccessException convertHibernateAccessException(HibernateException ex)

HibernateTemplate内部在实现HibernateException的异常转译的时候,最终也是委派该方法进行的。至于模板方法中需要处理的SQLException,HibernateTemplate则将这部分的转译工作转交给了SQLExceptionTranslator。通过学习前面的JdbcTemplate,我们对其并不陌生。

如果使用HibernateTemplate进行基于Hibernate的数据访问,我们无需关心具体的异常转译,因为HibernateTemplate内部可以很好地处理这一点。不过,即使不能够使用HibernateTemplate,也没关系,在基于Hibernate数据访问代码中,依然可以借助SessionFactoryUtils的convertHibernateAccessException方法进行异常的转译。

基本数据访问操作

HibernateOperations接口定义了能够通过HibernateTemplate使用的所有基于Hibermate的数据访问方法,HibernateTemplate实现了该接口。HibernateOperations的定义实在是太长,这里不详细罗列,在使用的过程中可以参考HibernateTemplate或者Hibernateoperations的Javadoc文档。

要使用HibernateTemplate进行数据访问,只要为其提供一个可以使用的SessionFactory实例即可。通过编程的方式提供还是通过Spring的IoC容器进行注入,完全可以根据具体应用场最来决定。

(1)基于HibernateTemplate的查询。HibernateTemplate为查询操作提供的模板方法比较丰富,主要分为如下4组。

这里不做介绍 有兴趣可以看原文

(2)基于HibernateTemplate的更新。我们这里的更新属于广义上的更新,包括数据的插入、更新和删除操作。HibernateTemplate为这些具体的操作同样提供了完善的模板方法支持,如下所述。

这里不做介绍 有兴趣可以看原文

2. Spring中的sessionFactory的配置及获取

Hibernate的SessionFactory,就好像JDBC的DataSource,它是所有数据访问资源的发源地。只有获取了SessionFactory的支持,后继的数据访问才能继续,这也是为什么HibernateTemplate必须拥有一个SessionFactory才能工作的原因。

要配置并构建一个SessionFactory,最简单的方法就是直接通过编程的方式获得,如下所示:

Configuration cfg = new Configuration()
	.addResource("mappingResource.hbm.xm1")
  ...
	.setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLInnoDBDialect")
  ...;
SessionFactory sessionFactory = cfg.buildSessionFactory();
// sessionFactory 处于可用状态

不过,这里要说的是在Spring中如何配置和获取SessionFactory,这些基本的方式就先放在一边不谈。

LocalSessionFactoryBean

Spring采用FactoryBean的形式对SessionFactory的配置和获取进行封装,org.springframework.orm.hibernate3.LocalSessionFactoryBean将是我们在Spring中配置和获取SessionFactory最为常用的方式。

LocalSessionFactoryBean作为一个FactoryBean实现,其对应的getobject()方法将返回SessionFactory类型的对象。我们可以通过LocalSessionFactoryBean配置Hibernate数据访问相关的所有资源,包括DataSource、配置文件位置、映射文件位置甚至于处理LOB数据的LobHandler。

下方代码清单给出了LocalSessionFactoryBean在Spring的IoC容器中的常见配置情况。

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="c1ose">
	<property name="url">
		<value>$(jdbc.url)</value>
	</property>
	<property name="driverClassName">
		<value>$(jdbc.driver]</value>
	</property>
	<property name="username">
		<value>$(jdbc.username)</value>
	</property>
	<property name="password">
		<value>$fjdbc.password)</value>
	</property>
</bean>
  
<bean id="sessionFactory" class="org.springframework.onm.hibernate3.Loca1SessionFactoryBean">
  <property name="dataSource" ref="dataSource"/>
	<property name="configLocation">
		<value>org.spring21..hibernate.cfg.xml</value>
	</property>
</bean>

Spring为了能够以统一的方式对各种数据访问方式的事务管理进行抽象,在通过LocalSessionFactoryBean构建SessionFactory的时候,使用的是容器内定义的DataSource定义,而不是使用Hibermate内部的ConnectionProvider。

实际上,在构建SessionFactory的实际过程中,Spring将根据传入的DataSource来决定为将要构建的SessionFactory提供什么样的ConnectionProvider实现。这些ConnectionProvider实现包括LocalDataSourceConnectionProvider以及TransactionAwareDataSourceConnectionProvider,我们可以在LocalSessionFactoryBean同一包下面找到它们。

在上方代码清单所示的容器配置文件中,只通过configLocation就完成了整个的LocalSessionFactoryBean的配置,这是因为通常的hibernate.cfg.xml配置文件中已经包含了几乎所有必需的配置信息,包括映射文件资源、各种Hibernate配置参数等。

AnnotationSessionFactoryBean

Hibernate从2.x版本就支持基于XML的映射文件来定义映射信息。不过,ORM的映射信息可以通过多种方式来表达。随着Java5的普及,越来越多的开发人员喜欢使用Java5中的注解来记录一些元数据信息。Hibernate在这一点上自然也不落后,通过Hibernate注解的支持,Hibernate中使用的映射信息也可以通过注解的形式来表达。而AnnotationSessionFactoryBean就是为那些通过注解获取映射信息的SessionFactory的配置以及构建而准备的。

AnnotationSessionFactoryBean是在LocalSessionFactoryBean基础上构建的,除了可以指定LocalSessionFactoryBean的配置项之外,AnnotationSessionFactoryBean追加定义了几个专门用于获取注解元数据定义类的配置项,包括annotatedClasses、annotatedPackages以及configurationClass。下方代码清单是AnnotationSessionFactoryBean的简单配置实例。

<bean id="sessionFactory" class="org.springframework.orm.hibennate3.annotation.AnnotationSessionFactoryBean">
	<property name="dataSource" ref="dataSource">
	<property name="annotatedClasses">
		<list>
			<value>cn.spring21..mapping.AnnotationMappingClass1</value>
			<value>cn.spring21..mapping.AnnotationMappingClass1</value>
		</list>
	</property>
	<propertyn ame="annotatedPackages">
		<list>
			<value>cn.spring21..package</value>
		</list>
	</property>
</bean>

因为标注有映射信息注解的类也可以在hibernate.cfg.xml之类的统一的配置文件中配置,所以,这种情况下,也可以不使用annotateaClasses之类的属性,直接使用一个configLocation属性配置即可搞定。

通过JNDI获取SessionFactory

除了可以在本地直接构建SessionFactory实例使用,或者通过Spring的IoC容器注册LocalSessionFactoryBean或者AnnotationSessionFactoryBean来获取相应的SessionFactory支持,我们也可以将SessionFactory绑定到服务器端的JNDI服务上,当需要使用的时候,可以通过JNDI查询来获得。

但将SessionFactory通过JNDI或者JCA绑定到具体的容器中是否必要却有值得商榷的地方。通过LocalSessionFactoryBean或者AnnotationSessionFactoryBean,在Spring容器中本地定义并获取sessionFactory,对于通常的应用程序来说是最为合适的方式,而通过JNDI绑定到具体容器则无法获取任何益处。 SessionFactory所持有的配置信息以及资源很大一部分是应用程序独有的,比如DomainObject,这不同于DataSource,将这些独有的信息绑定到JNDI再去获取,就好像你自己家的电视机必须放到一个地方去保管,当你要看的时候,还需要到那个地方去申请领回一样。

但对于某些场景来说,通过JCA来注册SessionFactory确实可以获得一定的优势,如结合EJB使用的时候。

总之,是否要通过JNDI来获取SessionFactory应该根据具体应用程序的场景来决定,但一般情况下,基于SpringIoC容器的SessionFactory配置及构建,就已经是最佳方案了。

3. HibernateDaoSupport

与JdbcDaoSupport所完成的使命相同,即使我们可以在DAO中直接使用HibernateTemplate进行数据访问,但也没有必要每个开发人员在各自的每个DAO实现类中都声明一个HibernateTemplate的实例。通常我们会提供一个DAO的基类,其中声明HibernateTemplate的支持,这样,子类只需要使用父类提供的HibernateTemplate进行数据访问操作即可。

HibernateDaoSupport的出现让我们免于重新去发明这种基于HibernateTemplate的DAO基类的轮子。在实现基于HibernateTemplate的DAO实现类的时候,我们直接继承HibernateDaoSupport就可以获得HibernateTemplate的数据访问支持,如下方代码清单所示。

public class FooHibernateDao extends HibernateDaoSupport implements IFooDao {
    public void insertNews(FXNewsBean newsBean) {
        getHibernateTemplate().save(newsBean);
    }

    public void deleteNews(Object po) {
        getHibernateTemplate().delete(po);
    }
    
    ...
}

HibernateDaoSupport还为子类公开了异常转译的方法,如下所示:

protected final DataAccessException convertHibernateAccessException(HibernateException ex)

即使在具体的DAO实现类中使用原始的HibernateAPI进行数据访问,只要我们继承了HibernateDaoSupport,也可以获得HibernateException到Spring统一异常体系的转译支持。


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明原文出处。如若内容造成侵权/违法违规/事实不符,请联系SD编程学习网:675289112@qq.com进行投诉反馈,一经查实,立即删除!