基于Spring框架的WebSphere应用开发(3)

＜servlet＞
＜servlet-name＞Dispatcher＜/servlet-name＞
＜servlet-class＞
org.springframework.web.servlet.DispatcherServlet
＜/servlet-class＞
＜load-on-startup＞2＜/load-on-startup＞
＜/servlet＞
＜init-param＞
＜param-name＞contextConfigLocation＜/param-name＞
＜param-value＞/WEB-INF/context/Webcontrollers.xml＜/param-value＞
＜/init-param＞
　　2.4 数据持久化层

　　虽然使用J2EE技术的Web应用可以连接多种不同的企业信息系统（EIS），但是毫无疑问数据库是其中最为重要和常见的一种。正因如此，Spring对数据库访问提供了非常完备的支持。数据访问对象（DAO）模式是J2EE模式中非常重要的一种。它的主要目的是使得持久化层与业务逻辑层分离，从而屏蔽持久化层的具体实现。我们可以把Spring的DAO支持分为两大类，一是直接基于Spring JDBC模板的数据访问，另一类是基于某种O/R映射框架的数据访问。这里刚好可以使用Spring的控制反转特性，通过外部配置文件来定义DAO接口和实际实现类之间的关系。Spring框架目前支持的O/R映射框架包括Hibernate、JDO、TopLink、iBATIS等。

　　假设我们定义了一个userDAO。当使用JDBC来实现这个DAO的时候，定义的类可以如下所示：

public class userDAOJDBC extends JdbcDaoSupport implements userDAO{ … }
　　如果使用Hibernate来实现这个DAO的时候，定义的类如下：

public class UserDAOHibernate extends HibernateDaoSupport implements UserDAO { … }
　　Spring对于其它的O/R映射机制都有相应的抽象类供应用使用，比如对于iBATIS有SqlMapClientDaoSupport，对于JDO有JdoDaoSupport等。

　　下面我们看一下如何在Spring的配置文件中定义上述DAO与具体实现的关系。假设我们的userDAO具体实现是通过Hibernate，那么在applicationContext.xml中的一个DAO可以定义如下：

＜bean id="userDAO" class="com.fgw.dao.hibernate.UserDAOHibernate"＞
＜property name="sessionFactory"＞
＜ref local="sessionFactory"/＞
＜/property＞
＜/bean＞
　　在这里我们实际DAO接口定义是：com.fgw.dao.UserDAO，而具体实现类为：com.fgw.dao.hibernate.UserDAOHibernate。显然，对于其它DAO的实现，我们只需要在配置文件中修改相应的实现类（具体实现类当然是比不可少的）和属性即可。比如对于JDBC的DAO实现，属性就定义成相应的数据源。

　　3、Spring与WebSphere应用服务器的配合

　　Spring与底层J2EE应用服务器还是存在一些需要结合的地方，这里给出WAS中的一些结合点。

　　3.1 使用WAS数据源

　　在Java应用程序中，数据库的连接一般有两种方式来得到。一种是通过java.sql.DriverManager的方式来得到数据库连接。这种方式不依赖于应用服务的支持，但是也不提供数据库连接池的功能。另外一种方式是通过javax.sql.DataSource的方式来得到数据库连接。在传统基于J2EE的应用需要通过JNDI来得到数据源（javax.sql.DataSource）对象，然后再通过数据源来得到相应的数据库连接。常见的应用服务器都支持这种方式，且一般都提供了数据库连接池的支持。虽然说我们一般推荐使用数据库连接池，但是也有一些时候我们需要脱离开应用服务器的环境使用数据库（比如单元测试，比如应用移植等）。然而应用程序使用这两种方式的时候代码是不一样的，因此只能通过代码来应变。Spring提供了一个统一使用数据源的解决方案，然后通过控制反转的机制用外部配置文件来指定使用的数据源。这样一方面可以统一这两种得到数据库连接的方式，另一方面也不需要像通常的J2EE应用通过繁琐的JNDI代码来得到数据源。这样应用程序也就不需要知道使用的何种数据源。

　　Spring提供了一个DriverManagerDataSource类来统一第一种方式的数据源获取。如果使用WAS中的Cloudscape数据库，用外部配置文件可配置如下：

＜bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"＞
＜property name="driverClassName"＞
＜value＞com.ibm.db2j.jdbc.DB2jDriver＜/value＞
＜/property＞
＜property name="url"＞
＜value＞jdbc:db2j:D:\\DBName＜/value＞
＜/property＞
＜/bean＞
　　Spring提供了JndiObjectFactoryBean类来支持第二种方式的数据源获取。假设WAS中已经配置好的数据源名称为jdbc /MyDB，那么用外部配置文件可配置如下：

＜bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean"＞
＜property name="jndiName"＞＜value＞java:comp/env/jdbc/MyDB＜/value＞＜/property＞
＜/bean＞
或者
＜bean id="dataSource"
class="org.springframework.jndi.JndiObjectFactoryBean"＞
＜property name="jndiName"＞＜value＞jdbc/MyDB＜/value＞＜/property＞
＜property name="resourceRef"＞＜value＞true＜/value＞＜/property＞
＜/bean＞
　　从上面配置我们可以得知，通过使用Spring，应用程序能够统一使用不同的数据源实现。如果使用环境发生变化，那么只需要修改Spring的配置文件即可。对于部署在WAS上的Web应用，在生产环境中推荐使用WAS实现的数据库连接池。一方面是因为连接池实现地比较完善。另一方面，使用WAS提供的数据库连接池可以很完善地支持JTA事务。

　　3.2 使用WAS的JTA

　　Web应用程序在使用事务的时候常常会涉及一个事务类型的选择。是选择像JDBC事务这样的本地事务呢还是使用JTA支持的全局事务。这个与应用程序需要涉及到的事务管理器类型和个数密切相关。Spring本身不支持分布式事务，因此分布式事务需要底层的JTA。但是Spring提供了事务的抽象，即底层真正事务实现可以切换而不影响应用程序代码。这样应用程序可以依赖于底层WAS，也可以轻易地脱离开应用服务器的环境。这一点与前面数据源的抽象非常类似。

　　WAS本身对于事务划分有两种支持方式，一种是声明式的，当然这种管理方式需要EJB容器的支持，即所谓的容器管理事务（CMT）。另外一种方式是编程式的，通过程序代码来直接使用JTA编程接口。Spring对于事务的划分也可以分为声明式和编程式两种方式。对于Spring编程式的事务划分方式，总体上可以分为两大类。一类是通过直接使用实现PlatformTransactionManager接口的类。另一类是通过使用TransactionTemplate模板类，模板类的使用可以简化事务控制代码。Spring对于声明式事务划分的支持实际上是利用了它的AOP机制。相对于编程式事务划分，这种基于AOP的方式比较灵活，而且对代码的侵入性几乎为零。因此，如果没有特殊需要推荐使用这种事务划分方式。基于AOP的常用事务划分方式可以使用ProxyFactoryBean加TransactionInterceptor方式，或者使用TransactionPorxyFactoryBean的方式。前一种方式相对比较灵活，而后一种则对使用相对比较简单。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有