关键字 J2EE Spring Acegi

[简介]

对于一个典型的Web应用，完善的认证和授权机制是必不可少的，在SpringFramework中，Juergen Hoeller提供的范例JPetStore给了一些这方面的介绍，但还远远不够，Acegi是一个专门为SpringFramework提供安全机制的 项目，全称为Acegi Security System for Spring，当前版本为0.5.1，就其目前提供的功能，应该可以满足绝大多数应用的需求。

本文的主要目的是希望能够说明如何在基于Spring构架的Web应用中使用Acegi，而不是详细介绍其中的每个接口、每个类。注意，即使对已经存在的Spring应用，通过下面介绍的步骤，也可以马上享受到Acegi提供的认证和授权。

[基础工作]
在你的Web应用的lib中添加Acegi下载包中的acegi-security.jar

[web.xml]
实现认证和授权的最常用的方法是通过filter，Acegi亦是如此，通常Acegi需要在web.xml添加以下5个filter:

<filter>
<filter-name>Acegi Channel Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.securechannel.ChannelProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.basicauth.BasicProcessingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class>
</filter>
<filter>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter</param-value>
</init-param>
</filter>

最先引起迷惑的是net.sf.acegisecurity.util.FilterToBeanProxy，Acegi自己的文档上解释是： “What FilterToBeanProxy does is delegate the Filter’s methods through to a bean which is obtained from the
Spring application context. This enables the bean to benefit from the Spring application context lifecycle support and configuration flexibility.”，如希望深究的话，去看看源代码应该不难理解。

再下来就是添加filter-mapping了：
<filter-mapping>
<filter-name>Acegi Channel Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP BASIC Authorization Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

这里，需要注意以下两点：
1) 这几个filter的顺序是不能更改的，顺序不对将无法正常工作；
2) 如果你的应用不需要安全传输，如https，则将”Acegi Channel Processing Filter”相关内容注释掉即可；
3) 如果你的应用不需要Spring提供的远程访问机制，如Hessian and Burlap，将”Acegi HTTP BASIC Authorization
Filter”相关内容注释掉即可。

[applicationContext.xml]
接下来就是要添加applicationContext.xml中的内容了，从刚才FilterToBeanFactory的解释可以看出，真正的filter都
在Spring的applicationContext中管理：

1) 首先，你的数据库中必须具有保存用户名和密码的table，Acegi要求table的schema必须如下：

CREATE TABLE users (
username VARCHAR(50) NOT NULL PRIMARY KEY,
password VARCHAR(50) NOT NULL,
enabled BIT NOT NULL
);
CREATE TABLE authorities (
username VARCHAR(50) NOT NULL,
authority VARCHAR(50) NOT NULL
);
CREATE UNIQUE INDEX ix_auth_username ON authorities ( username, authority );
ALTER TABLE authorities ADD CONSTRAINT fk_authorities_users foreign key (username) REFERENCES users
(username);

2) 添加访问你的数据库的datasource和Acegi的jdbcDao，如下：

<bean id=”dataSource” class=”org.springframework.jdbc.datasource.DriverManagerDataSource”>
<property name=”driverClassName”><value>${jdbc.driverClassName}</value></property>
<property name=”url”><value>${jdbc.url}</value></property>
<property name=”username”><value>${jdbc.username}</value></property>
<property name=”password”><value>${jdbc.password}</value></property>
</bean>
<bean id=”jdbcDaoImpl” class=”net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl”>
<property name=”dataSource”><ref bean=”dataSource”/></property>
</bean>

3) 添加DaoAuthenticationProvider:

<bean id=”daoAuthenticationProvider” class=”net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider”>
<property name=”authenticationDao”><ref bean=”authenticationDao”/></property>
<property name=”userCache”><ref bean=”userCache”/></property>
</bean>

<bean id=”userCache” class=”net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache”>
<property name=”minutesToIdle”><value>5</value></property>
</bean>

如果你需要对密码加密，则在daoAuthenticationProvider中加入：<property name=”passwordEncoder”><ref
bean=”passwordEncoder”/></property>，Acegi提供了几种加密方法，详细情况可看包
net.sf.acegisecurity.providers.encoding

4) 添加authenticationManager:

<bean id=”authenticationManager” class=”net.sf.acegisecurity.providers.ProviderManager”>
<property name=”providers”>
<list>
<ref bean=”daoAuthenticationProvider”/>
</list>
</property>
</bean>

5) 添加accessDecisionManager:

<bean id=”accessDecisionManager” class=”net.sf.acegisecurity.vote.AffirmativeBased”>
<property name=”allowIfAllAbstainDecisions”>
<value>false</value>
</property>
<property name=”decisionVoters”>
<list><ref bean=”roleVoter”/></list>
</property>
</bean>
<bean id=”roleVoter” class=”net.sf.acegisecurity.vote.RoleVoter”/>

6) 添加authenticationProcessingFilterEntryPoint:

<bean id=”authenticationProcessingFilterEntryPoint”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint”>
<property name=”loginFormUrl”><value>/acegilogin.jsp</value></property>
<property name=”forceHttps”><value>false</value></property>
</bean>

其中acegilogin.jsp是登陆页面，一个最简单的登录页面如下：

<%@ taglib prefix=’c’ uri=’http://java.sun.com/jstl/core’ %>
<%@ page import=”net.sf.acegisecurity.ui.AbstractProcessingFilter” %>
<%@ page import=”net.sf.acegisecurity.AuthenticationException” %>
<html>
<head>
<title>Login</title>
</head>

<body>
<h1>Login</h1>
<form action=”<c:url value=’j_acegi_security_check’/>” method=”POST”>
<table>
<tr><td>User:</td><td><input type=’text’ name=’j_username’></td></tr>
<tr><td>Password:</td><td><input type=’password’ name=’j_password’></td></tr>
<tr><td colspan=’2′><input name=”submit” type=”submit”></td></tr>
<tr><td colspan=’2′><input name=”reset” type=”reset”></td></tr>
</table>
</form>
</body>
</html>

7) 添加filterInvocationInterceptor:

<bean id=”filterInvocationInterceptor”
class=”net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”accessDecisionManager”>
<ref bean=”accessDecisionManager”/>
</property>
<property name=”objectDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=ROLE_SUPERVISOR
\A/sec/user.*\Z=ROLE_TELLER
</value>
</property>
</bean>

这里请注意，要objectDefinitionSource中定义哪些页面需要权限访问，需要根据自己的应用需求进行修改，我上面给出
的定义的意思是这样的：
a. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON意思是在比较请求路径时全部转换为小写
b. \A/sec/administrator.*\Z=ROLE_SUPERVISOR意思是只有权限为ROLE_SUPERVISOR才能访问/sec/administrator*的页面
c. \A/sec/user.*\Z=ROLE_TELLER意思是只有权限为ROLE_TELLER的用户才能访问/sec/user*的页面

8) 添加securityEnforcementFilter:

<bean id=”securityEnforcementFilter” class=”net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter”>
<property name=”filterSecurityInterceptor”>
<ref bean=”filterInvocationInterceptor”/>
</property>
<property name=”authenticationEntryPoint”>
<ref bean=”authenticationProcessingFilterEntryPoint”/>
</property>
</bean>

9) 添加authenticationProcessingFilter:

<bean id=”authenticationProcessingFilter”
class=”net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter”>
<property name=”authenticationManager”>
<ref bean=”authenticationManager”/>
</property>
<property name=”authenticationFailureUrl”>
<value>/loginerror.jsp</value>
</property>
<property name=”defaultTargetUrl”>
<value>/</value>
</property>
<property name=”filterProcessesUrl”>
<value>/j_acegi_security_check</value>
</property>
</bean>
其中authenticationFailureUrl是认证失败的页面。

10) 如果需要一些页面通过安全通道的话，添加下面的配置:

<bean id=”channelProcessingFilter” class=”net.sf.acegisecurity.securechannel.ChannelProcessingFilter”>
<property name=”channelDecisionManager”>
<ref bean=”channelDecisionManager”/>
</property>
<property name=”filterInvocationDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/sec/administrator.*\Z=REQUIRES_SECURE_CHANNEL
\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
\A.*\Z=REQUIRES_INSECURE_CHANNEL
</value>
</property>
</bean>

<bean id=”channelDecisionManager” class=”net.sf.acegisecurity.securechannel.ChannelDecisionManagerImpl”>
<property name=”channelProcessors”>
<list>
<ref bean=”secureChannelProcessor”/>
<ref bean=”insecureChannelProcessor”/>
</list>
</property>
</bean>
<bean id=”secureChannelProcessor” class=”net.sf.acegisecurity.securechannel.SecureChannelProcessor”/>
<bean id=”insecureChannelProcessor” class=”net.sf.acegisecurity.securechannel.InsecureChannelProcessor”/>

[缺少了什么？]
Acegi目前提供了两种”secure object”，分别对页面和方法进行安全认证管理，我这里介绍的只是利用
FilterSecurityInterceptor对访问页面的权限控制，除此之外，Acegi还提供了另外一个Interceptor–
MethodSecurityInterceptor，它结合runAsManager可实现对对象中的方法的权限控制，使用方法可参看Acegi自带的文档
和contact范例。

[最后要说的]
本来以为只是说明如何使用Acegi而已，应该非常简单，但真正写起来才发现想要条理清楚的理顺所有需要的bean还是很
困难的，但愿我没有遗漏太多东西，如果我的文章有什么遗漏或错误的话，还请参看Acegi自带的quick-start范例，但请
注意，这个范例是不能直接拿来用的。

原文在这里：

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=54881

 二、ThreadLocal是相对于每个session的

        ThreadLocal顾名思义，是针对线程。在java web编程上，每个用户从开始到会话结束，都有自己的一个session标识。但是ThreadLocal并不是在会话层上。其实，Threadlocal是独立于用户session的。它是一种服务器端行为，当服务器每生成一个新的线程时，就会维护自己的ThreadLocal。对于这个误解，个人认为应该是开发人员在本地基于一些应用服务器测试的结果。众所周知，一般的应用服务器都会维护一套线程池，也就是说，对于每次访问，并不一定就新生成一个线程。而是自己有一个线程缓存池。对于访问，先从缓存池里面找到已有的线程，如果已经用光，才去新生成新的线程。所以，由于开发人员自己在测试时，一般只有他自己在测，这样服务器的负担很小，这样导致每次访问可能是共用同样一个线程，导致会有这样的误解：每个session有一个ThreadLocal

 三、ThreadLocal是相对于每个线程的，用户每次访问会有新的ThreadLocal

  理论上来说，ThreadLocal是的确是相对于每个线程，每个线程会有自己的ThreadLocal。但是上面已经讲到，一般的应用服务器都会维护一套线程池。因此，不同用户访问，可能会接受到同样的线程。因此，在做基于TheadLocal时，需要谨慎，避免出现ThreadLocal变量的缓存，导致其他线程访问到本线程变量

 四、对每个用户访问，ThreadLocal可以多用
        可以说，ThreadLocal是一把双刃剑，用得来的话可以起到非常好的效果。但是，ThreadLocal如果用得不好，就会跟全局变量一样。代码不能重用，不能独立测试。因为，一些本来可以重用的类，现在依赖于ThreadLocal变量。如果在其他没有ThreadLocal场合，这些类就变得不可用了。个人觉得ThreadLocal用得很好的几个应用场合，值得参考

  1、存放当前session用户：quake want的jert

  2、存放一些context变量，比如webwork的ActionContext

  3、存放session，比如Spring hibernate orm的session

最终还是调用到了getBeanFactory().destroySingletons(); 看来，没有容器，我们还是需要自己来搞定这个方法的调用的 ！

						/**
* @hibernate.class table="CATEGORY"
*/ 
public class Category {
   private Long id;

   private String name;

   /**
    * @hibernate.id generator-class="native" column="CATEGORY_ID"
    */
   public Long getId() {
      return id;
   }

   public void setId(Long id) {
      this.id = id;
   }

   /**
    * @hibernate.property column="NAME"
    */
   public String getName() {
      return name;
   }

   public void setName(Long name) {
      this.name = name;
   }
}

/**
* @hibernate.class table="PRODUCT"
*/
public class Product {
   private Long id;
   private Category category;

   /**
    * @hibernate.id generator-class="native" column="PRODUCT_ID"
    */
   public Long getId() {
      return id;
   }

   public void setId(Long id) {
      this.id = id;
   }

   /**
    * @hibernate.many-to-one
    * column="CATEGORY_ID"
    * class="Category"
    * cascade="none"
    * not-null="false"
    */
   public Category getCategory() {
      return category;
   }

   public void setCategory(Category category) {
      this.category = category;
   }
}
				

						<select name="categoryId">
   <option value="">No Category</option>
   <option value="1">Category 1</option>
   <option value="2">Category 2</option>
   <option value="3">Category 3</option>
</select>
				

						<html:select property="category.id">
   <option value="">No Category</option>
   <html:options collection="categories" property="id" labelProperty="name"/>
</html:select>

				

						public class ProductForm extends ActionForm {
     private Long id;
     private Category category;
     ...
} 
				

						public class ProductForm extends ActionForm {
     private Long id;
     private Category category;
     ...
     public void reset(ActionMapping mapping, HttpServletRequest request) 
     {
        super.reset( mapping, request );
        if ( category == null ) { category = new Category(); }
     }
} 
				

						public class EditProductAction extends Action {
     public final ActionForward execute( ActionMapping mapping, ActionForm form, 
        HttpServletRequest request, HttpServletResponse response ) throws Exception
     {
        ...
        Product product = createOrLoadProduct();
        ProductForm productForm = (ProductForm)form;
        PropertyUtils.copyProperties( productForm, product );
        productForm.reset( mapping, request );
        ...
     }
} 
				

						      Product product = createOrLoadProduct();
        PropertyUtils.copyProperties( form, product );
        form.reset( mapping, request );
				

						public class ProductForm extends ActionForm {
     private Long id;
     private Category category;
     ...
     public void reset(ActionMapping mapping, HttpServletRequest request) {
        super.reset( mapping, request );
        if ( category == null ) { category = new Category(); }
     }

     public void cleanupEmptyObjects() {
        if ( category.getId() == null ) { category = null; }
     }
}
				

						public class SaveProductAction extends Action {
     public final ActionForward execute( ActionMapping mapping, ActionForm form, 
        HttpServletRequest request, HttpServletResponse response ) throws Exception
     {
        ...
        Product product = new Product();
        ((ProductForm)form).cleanupEmptyObjects();
        PropertyUtils.copyProperties( product, form );
        SaveProduct( product );
        ...
     }
} 
				

						public class Category {
     ...
     private Set products;
     ...

     /**
      * @hibernate.set
      * table="PRODUCT"
      * lazy="true"
      * outer-join="auto"
      * inverse="true"
      * cascade="all-delete-orphan"
      * 
      * @hibernate.collection-key
      * column="CATEGORY_ID"
      * 
      * @hibernate.collection-one-to-many
      * class="Product"
      */
     public Set getProducts() {
        return products;
     }

     public void setProducts(Set products) {
        this.products = products;
     }
} 
				

						public class CategoryForm extends ActionForm {
     private Set productForms;
     ...
     public void reset(ActionMapping mapping, HttpServletRequest request) {
        super.reset( mapping, request );

        for ( int i = 0; i < MAX_PRODUCT_NUM_ON_PAGE; i++ ) {
           ProductForm productForm = new ProductForm();
           productForm.reset( mapping, request );
           productForms.add( productForm );
        }
     }

     public void cleanupEmptyObjects() {
        for ( Iterator i = productForms.iterator(); i.hasNext(); ) {
           ProductForm productForm = (ProductForm) i.next();
           productForm.cleanupEmptyObjects();
        }
     }
} 
				

						import java.beans.PropertyDescriptor;
import org.apache.commons.beanutils.PropertyUtils;
import org.hibernate.metadata.ClassMetadata;

public abstract class AbstractForm extends ActionForm {
   public void reset(ActionMapping mapping, HttpServletRequest request) {
      super.reset( mapping, request );

      // Get PropertyDescriptor of all bean properties
      PropertyDescriptor descriptors[] = 
         PropertyUtils.getPropertyDescriptors( this );

      for ( int i = 0; i < descriptors.length; i++ ) {
         Class propClass = descriptors.getPropertyType();

         ClassMetadata classMetadata = HibernateUtil.getSessionFactory()
            .getClassMetadata( propClass );

         if ( classMetadata != null ) {   // This is a Hibernate object
            String propName = descriptors.getName();
            Object propValue = PropertyUtils.getProperty( this, propName );

            // Evaluate property, create new instance if it is null
            if ( propValue == null ) {
               PropertyUtils.setProperty( this, propName, propClass.newInstance() );
            }
         }
      }
   }

   public void cleanupEmptyObjects() {
      // Get PropertyDescriptor of all bean properties
      PropertyDescriptor descriptors[] =
      PropertyUtils.getPropertyDescriptors( this );

      for ( int i = 0; i < descriptors.length; i++ ) {
         Class propClass = descriptors.getPropertyType();
         ClassMetadata classMetadata = HibernateUtil.getSessionFactory()
            .getClassMetadata( propClass );

         if ( classMetadata != null ) {   // This is a Hibernate object
            Serializable id = classMetadata.getIdentifier( this, EntityMode.POJO );

            // If the object id has not been set, release the object.
            // Define application specific rules of not-set id here,
            // e.g. id == null, id == 0, etc.
            if ( id == null ) {
               String propName = descriptors.getName();
               PropertyUtils.setProperty( this, propName, null );
            }


         }
      }
   }
} 
				

     我厌倦一切配置文件繁重的框架。
     最好的情况是，框架提供极端灵活复杂的配置方式，但只在你需要的时候。
 
     Spring提供了三种可能来简化XML。随着国内用户水平的提高，这些基本的简化技巧大家都已掌握。
     大家可以直接看第3，第4点--Spring 1.2, Spring 2.0的后继改进。

1.1.autowire="byName" /"byType"

     假设Controller有一个属性名为customerDAO，Spring就会在配置文件里查找有没有名字为CustomerDAO的bean, 自动为Controller注入。
     如果bean有两个属性，一个想默认注入，一个想自定义，只要设定了autowire，然后显式的声明那个想自定义的，就可以达到要求。这就应了需求，在需要特别配置的时候就提供配置，否则给我一个默认注入。

     还有一个更懒的地方，在最最根部的<beans>节点写一句default-autovwrie="byName"，可以让文件里的所有bean 都默认autowrie。
    不过Rod认为开发期可以这样，但Production Server上不应该使用Autowire。而我觉得那些自定义一次的地方比如TranscationManager应该详细定义，而Dao,Controller这种大量重复定义的bean就可以偷点懒了。

1.2.<bean>节点之间抽象公共定义和 Inner Bean

    这太方便懒人了，想不到两个独立的XML节点都可以玩继承和派生，子节点拥有父节点的全部属性。
    最好用的地方就是那个Transtion Proxy的定义。先定义一个又长又冗的父类，然后用子类去继承它。
   
    另外，还有一个Inner Bean的机制，可以把DAO写成Proxy的内部类。为什么要写成内部类?为了让Proxy冒名顶替它去让Controller Autowire。(详见后面的示例)

1.3. 宽松的配置, To XML or Not to XML 
    据说Spring比Struts的配置宽松了很多，这就给人把东西从配置文件中撤回原码中的机会。
    不赞成什么都往配置文件里晒，造成了Rich Information的配置文件，修改或者查看的时候，要同时打开配置文件和原码才能清楚一切。
    而我希望配置文件就集中做一些整体的配置，还有框架必须的、无需管理的冗余代码。而一些细节的变化不大的配置和逻辑，就尽量别往里塞了。因此，Success/Fail View 的配置，不建议放在里面。

2.简化后的配置文件

1.Controller只剩下一句

2.DAO也只剩一句

3.Service类只剩下5行

3.Spring 1.2后xml语法简化

 最主要的简化是把属性值和引用bean从子节点变回了属性值，对不喜欢autowire的兄弟比较有用。
 当然，如果value要CDATA的时候还是要用子节点。另外，list的值可以用空格隔开也比较实用。

1.属性值

  <property name="foo">
     <value>fooValue</value>
  </property>
  简化为
  <property name="foo" value="fooValue"/>

2.引用 bean

<property name="foo">
   <ref bean="fooBean">
</property>
简化为
<property name="foo" ref="fooBean"/>

3. list可以简化为空格分开的字符串

 

<property name="myFriendList">
  <list>
     <value>gigix</value>
        <value>wuyu</value>
  </list>
</property>
简化为
<property name="myFriendList" value="gigix wuyu"/>

   
  
4.Spring 2.0来了
   如果没什么外力刺激，spring xml 可能就这样不会变了。但现在xml成了过街老鼠，被ror的默认配置和JDK5的annotation逼得不行，当然就要继续求变。
   比如有好事者认为，节点名必须以bean打头，附加一个属性id来表示bean名；属性值必须搞一个property子节点，子节点上有个属性name来表示属性名，是给机器看的很不直观的东西。

<bean id="customerDAO" class="org.springside...CustomerDAO">
 <property name="maxCount" value="10">
</bean>

给人看的东西应该就写成

<customerDAO class="org.springside....CustomerDAO" maxCount="10"/>

Spring 2.0正用schema实现类似的语法，具体请看它的JPetStore sample。

    如果没有用Eclipse的Spring插件，那至少也要使用spring自带的dtd使XML编辑器smart一些，能够自动为你生成属性,判断节点/属性名称有没有拼错等。

6.还有更变态的简化配置方法
    比如autoproxy，不过我觉得更简化就不可控了，所以没有采用。

因为Spring自带的sample离我们的实际项目很远，所以官方一点的model层模式展现就靠Appfuse了。
    但Appfuse的model层总共有一个DAO接口、一个DAOImpl类、一个Service接口、一个ServiceImpl类、一个DataObject.....大概只有受惯了虐待的人才会欣然接受吧。
    另外，Domain-Driven逢初一、十五也会被拿出来讨论一遍。

    其实无论什么模式，都不过是一种人为的划分、抽象和封装。只要在团队里理解一致，自我感觉优雅就行了。
     我的建议是，一开始DO和Manager一生一旦包演全场，DO作为纯数据载体，而Manager类放置商业方法，用getHibernateTemplate()直接访问数据库，不强制基于接口编程。当某天系统复杂到你直觉上需要将DAO层和Service层分开时，再分开就好了。

    1.DataObject类
     好听点也可以叫Domain Object。Domain Driven  Development虽然诱人，但因为Java下的ORM框架都是基于Data Mapper模式的，没有Ruby On Rails中那种Active Recorder的模式。所以，还是压下了这个欲望，Data Object纯粹作一个数据载体，而把数据库访问与商业逻辑操作统一放到Manager类中。

    2.Manager类
    我的Manager类是Appfuse中DAO类与Service类的结合体，因为：

    2.1 不想使用纯DAO
     以往的DAO是为了透明不同数据库间的差异，而现在Hibernate已经做的很好。所以目前纯DAO的更大作用是为了将来可以切换到别的ORM方案比如iBatis，但一个Pragmaic的程序员显然不会无聊到为了这个机会不大的理由，现在就去做一个纯DAO层，项目又不是Appfuse那样为了demo各种ORM方案而存在。

    2.2 也不使用纯的薄Service层
    在JPetStore里有一个很薄的Service层，Fascade了一堆DAO类，把这些DAO类的所有方法都僵硬的重复了一遍。而我认为Fascade的意义在二：
    一是Controller调用Manager甲的时候，总会伴随着调用Manager乙的某些方法。使用Fascade可以避免Controller零散的调用一堆Manager类。
    二是一个商业过程里可能需要同时调用DAO甲乙丙丁的方法。 

     这些时候，Fascade都是合理的。但我讨厌类膨胀，所以我宁愿在甲乙丙丁中挑一个来充当Fascade的角色。有耦合的问题吗？对一个不是死搬书的Designer来说，组件边界之内的类之间的耦合并不是耦合。

    3.去除不必要的基于接口编程
    众所周知，Spring是提倡基于接口编程的。
    但有些Manager类，比如SaleOrderManager ，只有5%的机会再有另一个Impl实现。95%时间里这两兄弟站一起，就像C++里的.h和.cpp，徒增维护的繁琐(经常要同步两个文件的函数声明)，和代码浏览跳转时的不便(比如从Controler类跟踪到Service类时，只能跳转到接口类的相应函数，还要再按一次复杂的热键才跳转到实现类)
    连Martin Flower都说，强制每个类都分离接口和实现是过犹不及。只在有多个独立实现，或者需要消除对实现类的依赖时，才需要分离接口。

    3.1 DAO被强制用接口的原因
    Spring IOC本身是不会强制基于接口的，但DAO类一般要使用Spring的声明式事务机制，而声明式的事务机制是使用Spring AOP来实现的。Spring AOP的实现机制包括动态代理和Cgilib2，其中Spring AOP默认使用的Java动态代理是必须基于接口，所以就要求基于接口了。
    
    3.2 解决方法
    那就让Spring AOP改用CGLib2，生成目标类的子类吧，我们只要指定使用声明式事务的FactoryBean使用CGLib的方式来实现AOP，就可以不基于接口编程了。
    指定的方式为设置proxyTargetClass为true。如下：

<bean class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
id="baseService"   abstract="true">
  <property name="transactionManager" ref="transactionManager"/>
  <property name="proxyTargetClass" value="true"/>

</bean>

     又因为这些Service Bean都是单例，效率应该不受影响。

    4.总结
    对比Appfuse里面的5个类，我的Model层里只有VO作为纯数据载体，Manager类放商业方法。有人说这样太简单了，但一个应用，要划成几个JSP，一个Controller，一个Manager，一个VO，对我来说已经足够复杂，再要往上架墙叠屋，恕不奉陪，起码在我的项目范围里不需要。(但有很多项目是需要的，神佑世人）

    后记：迫于世人的压力，SpringSide还是把DAO和Service层分开了，但依然坚持不搞那么多接口。

Struts与Webwork的扇子请跳过本篇。

    MVC不就是把M、V、C分开么？至唯物朴素的做法是两个JSP一个负责View，一个负责Controller，再加一个负责Model的Java Bean，已经可以工作得很好，那时候一切都很简单。
    而现在为了一些不是本质的功能，冒出这么多非标准的Web框架，实在让人一阵郁闷。像Ruby On Rails那样简捷开发，可用可不用，而且没有太多的限制需要学习的，比如Webwork这型还可以考虑。但像Struts那样越用框架越麻烦，或者像Tapestry那样有严重自闭倾向，额上凿着"高手专用玩具"的，用在团队里就是不负责任的行为了。

      最后还是忍不住提取了一个基类，负责MultiAction和其他一些简便的方法。Sprnig的MultiActionController做得太死，规定所有函数的第1,2个参数必须是request和response，不懂动态的，温柔的进行参数注入。

      
      经过化简再化简，已经是很简单一个Java Bean ，任谁都可以轻松上手，即使某年某月技术的大潮把现在所有MVC框架都淹没了，也不至于没人识得维护。
人生像个舞台，请良家少女离开。
    同样的，Freemarker和Velocity爱好者请跳过本篇。与弃用webwork而单用Spring MVC Controller接口的理由一样，Freemarker本来是一样好东西，还跨界支持jsp 的taglib，而且得到了WebWork的全力支持，但为了它的非标准化，用户数量与IDE的缺乏，在View层我们还是使用了保守但人人会用，IDE友好的JSP2.0 配合JSTL。

    对于B/S结构的企业应用软件来说，基本的页面不外两种，一种是填Form的，一种是DataGrid 数据列表管理的，再配合一些css, js, ajax的效果，就是View层要关注的东西了。

1. JSP 2.0的EL代替<c:out>
JSP2.0可以直接把EL写在html部分，而不必动用<c:out>节点后，老实说，JSP2.0+JSTL达到的页面效果，已不比Velocity相差多少了。

<p>{goods.name}</p> 
代替
<p><c:out value="{goods.name}"/></p>

(除了EL里面不能调用goods的函数，sun那帮老顽固始终坚持JSTL只能用于数据显示，不能进行数据操作，所以不能调用bean的get/set外的方法)

 2. 最懒的form 数据绑定

    Spring少得可怜的几个tag基本上是鸡肋，完全可以不要。 而Spring开发中的那些Simple Form tag又还没有发布。Spring的Tag主要用来把VO的值绑到input框上。但是，和Struts一样，需要逐个Input框绑定，而且语法极度冗长，遇到select框还要自己进行处理.....典型的Spring Sample页面让人一阵头晕.

    而jodd的form tag给了我们懒人一个懒得多的方法，只要在<form>两头用<jodd:form bean="myVO"></jodd:form>包住，里面的所有input框，select框，checkBox...统统自动被绑定了，这么简单的事情，真不明白struts,spring为什么不用，为了不必要的灵活性么?

<form>
<jodd:form bean="human">
<input type="text" name="name">
<input type="radiobox" name="sex" value="man">
<select name="age">
  <option value="20">20</option>
  <option value="30">30</option>
</select>
</jodd:form>
</form> 

不过，jodd有个致命弱点是不能绑定内嵌对象的值。比如Order(订单)对象里有个Customer(顾客)对象，jodd就不能像 struts,spring一样用如下语法绑定:

<input name="customer.customerNo">

这是因为它的beanUtils比Jakata Common弱，用了一个错误的思路的缘故。 动用beanUtils修改一下就可以了，修改后的源码可以在这里下载。

3. DataGrid数据列表

DisplayTag和ValueList都属于这种形式的Tag Library。但最近出现的Extreme Table是真正的killer，他本身功能强大不说，而且从一开始就想着如何让别人进行扩展重载，比如Extend Attributes机制就是DisplayTag这样的让千人一面者不会预留。


4.css, java script, ajax
天下纷扰，没有什么特别想讲想推荐的，爱谁谁吧。Buffalo, DWR, Scriptaculous, Prototype, AjaxTags, AjaxAnywhere, Rico, Dojo, JSON-RPC，看着名字就头痛。

    在使用Hibernate的应用中, Spring的对DAO对象通常的事务管理特别应该引起关注。它的目的就是分离数据访问和事务处理，使事务性业务对象不与任何特殊的数据访问或者事务策略绑在一起，从而不影响业务对象的可复用性。这种划分既可以经由事务模板（TransactionTemplate）用编程的方式实现，也可以经由面向方面（AOP）事务拦截器（TransactionTemplate）用声明的方式实现。无论是本地的Hibernate / JDBC事务，还是JTA事务都支持对象外的事务策略，这对于本地的无状态会话Bean（Stateless Session Beans）是一个非常有用的选择。

    Spring的HibernateTemplate类提供了一个简单的方式实现了Hibernate-based DAO对象而不必关心如何获得Hibernate的Session实例，也不必关心多方参与的事务处理。无需使用try-catch块，也无需进行事务检查。一个简单的Hibernate访问方法就完全解决了些麻烦! 无论是在多个DAO接口还是在多方事务的情况下，Spring使得多种DAO对象无缝地协同工作。例如：某些DAO对象可能是基于plain JDBC的实现，更适合于经由Spring的JdbcTemplate来避免手动的异常处理。

      你可以单独地使用许多Spring特性，因为Spring的所有对象都是设计成可复用的JavaBean对象的集合。也不要因为Spring可以提供一个完整的应该框架而气馁！使用其他的Spring特性时，应用配置概念是一个附加的特性，并不是一个必须的特性。无论如何，当你要决定去构建一个象Spring这样的内在的基础架构的时候，在使用Spring的路途上没有什么范围上的限制。

1. 介绍: 资源管理

       典型的业务应用系统常常由于重复的资源管理代码而导致混乱。许多项目试着用自己的方法来解决这个问题，有时要为此付出失败的代价，Spring针对适当的资源管理提倡了一种引人注目的简单方法：即经由模板来倒置控制（Inversion of control），例如：基础类使用回调接口，或者应用AOP拦截器。其基础核心是适当的资源处理和将特殊的API异常转换为一个unchecked的基础异常。

       Spring引入了一个DAO异常层适用于任何数据访问策略。对于直接的JDBC，JdbcTemplate类关注于连接处理，并且关注于对SQLException转换为适当的DataAccessException，包括对特殊的数据库SQL错误转换为有意义的异常。 经由不同的事务管理对象，Spring支持JTA和JDBC事务。Spring 也提供对Hibernate和JDO的支持，它的这种支持由与JdbcTemplate类的作用相类似的HibernateTemplate类和JdoTemplate类, 以及HibernateInterceptor类、JdoInterceptor类，还有Hibernate、JDO 事务管理类组成。

       最主要的目的是要使应用的层次分明，为此将数据访问和事务处理同应用对象分离开来。所有的业务对象都不再依赖数据访问或者事务策略。不再有硬编码的资源查找代码，不再有难以替换的单例对象，也不再需要定制服务注册。

      所有的单独的数据访问特性均无需依赖于Spring，可以单独使用，无需让Spring知道，同时也可以通过Spring的应用配置（提供基于XML的配置和对普通JavaBean实例的交叉引用）来进行装配。在一个典型的Spring应用中，大部分重要的对象都是普通的JavaBean：数据访问模板对象（data access templates）、数据访问对象（使用数据访问模板对象的对象）、事务管理对象及业务对象（使用数据访问对象和事务对象的对象），web表示分解对象、web控制对象（使用业务对象的对象）等等。

2. 应用配置中的资源定义

    为了避免应用对象将资源查找的代码硬编码，Spring允许在应用配置中将一个如JDBC DataSource或者Hibernate SessionFactory定义为一个Bean。应用对象如果需要访问资源只需要通过Bean引用（DAO定义在下一部分说明）接受先前定义的实例的引用。以下的内容引用自一个应用配置定义，显示了如何建立一个JDBC DataSource和一个Hibernate的SessionFactory：

      注意选择是用JNDI来定位数据源还是从一个象Jakarta Commons DBCP BasicDataSource这样的本地定义取得一个数据源，只是一个改变配置的事：

       你也可以使用一个JNDI查找SessionFactory，但是通常对于EJB环境之外的应用来说并不是需要的（参考"container resources vs local resources"部分的讨论）。

3. 倒置控制（Inversion of Control）: 模板和回调

    模板的基本编程模式就象你将在下面看到那样，至于方法就如同任何定制的数据访问对象或者业务的对象的方法一样。除了需要向其提供一个Hibernate的SessionFactory之外，再没有对周围执行对象的信赖的限制。虽然最好是从一个Spring的应用配置中经由一个简单setSessionFactory bean的属性设置使用Bean引用来获得它，但随后你可以从任何地方获得它。随后的引用片段包括一段在Spring应用配置中对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;
}
}
);
}
}

       一个回调的实现可以被有效地用在任何Hibernate数据访问中。在任何情况下都由HibernateTemplate来管理Session的开闭和自动的多方事务。模板实例是线程安全和可重用的，因此它们可以做为其他类的变量。

       对于简单的单步的动作，象find, load, saveOrUpdate或者delete的调用，HibernateTemplate提供更为便利的选择以代替象一行的回调的执行。此外，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);
}
}

4. 应用一个AOP拦截器代替一个模板

   除使用HibernateTemplate之外的另一个选择就是使用Spring的AOP HibernateInterceptor。用直接在一个委托的try/catch块中编写Hibernate代码，配合相应的在应用配置中分别的拦截器配置来代替执行回调。下面的片段显示了一个Spring应用配置中的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时才能正常工作，HibernateInterceptor为它负责在方法调用前线程绑定Session的开启和方法调用后的关闭。getSession方法调用中的"false"标志是要确认Session必须是已经存在的，如果没有发现任何一个Session，SessionFactoryUtils将会为其创建一个。如果已经有一个Session句柄绑定在本线程上，比如是由一个HibernateTransactionManager事务绑定的，在任何情况下SessionFactoryUtils会自动接入这个Session。HibernateTemplate在底层也使用SessionFactoryUtils，与以上说的方式基本是一样的。

       HibernateInterceptor的主要益处是它允许在数据访问代码中抛出checked application exception，而HibernateTemplate由于受限于回调只能在其中抛出unchecked exceptions。注意到这点我们可以推迟各自的检验，同时在回调后抛出应用异常。拦截方式的主要缺点是它需要在配置中进行特殊的配置。HibernateTemplate在大多数情况下都是一种简单好用的方法。

5. 程序事务划分

   在这种底层的数据访问服务之上，事务处理可以在更高的应用层被划分 ，形成一些操作。这里除了需要一个Spring的PlatformTransactionManager对象外，对于周围运行的业务对象也没有任何限制。同样的，其后你可以从任何地方获得它们，但是经由Bean引用的方式通过setTransactionManage方法获得更为适合，象productDAO要经由一个setProductDao方法获得一样。下面的引用片段显示了在一个Spring应用配置中的事务管理对象和业务对象的定义，并且还提供了一个业务方法实现的例子：

<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);
...
}
}
);
}
}

6. 声明性事务划分

       我们还可以选择使用Spring的AOP TransactionInterceptor通过在应用配置中定义拦截器配置来代替事务划分代码的事务处理方式。这允许我们保持业务对象独立于每个业务对象中重复的事务划分代码。此外，事务行为和隔离层次的变化可以通过一个配置文件来改变而不需要对业务对象的实现造成影响。

<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 application exception从回调代码中抛出，而TransactionTemplate受回调限制在其内部抛出unchecked exceptions，在出现一个unchecked application exception的情况时，TransactionTemplate将引发一个回滚或者这个事务由应用（通过事务状态）标记为回滚。TransactionInterceptor默认情况也是同样的行为，但是允许为每一个方法制定回滚策略。
       建立声明性事务的一个便利的方式是使用TransactionProxyFactoryBean，特别是如果没有其他AOP拦截器的话，TransactionProxyFactoryBean将联合定义为代理的自身与一个特殊的目标Bean的事务配置。这将减少一个代理Bean对应一个目标Bean的配置情况。此外，你不必指定哪个接口或者哪个类必须定义事务方法。

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

7. 事务管理策略

          对于Hibernate应用来说，无论是TransactionTemplate还是TransactionInterceptor都是委托验实际的事务处理给PlatformTransactionManager实例，可以是一个HibernateTransactionManager（由一个单一的Hibernate的SessionFactory，使用一个ThreadLocal Session）或者可以是一个JtaTransactionManager（代理容器的JTA子系统）。甚至你可以使用一个自定义的PlatformTransactionManager实现。
       如果选择从本地Hibernate事务管理转为由JTA来进行事务管理，例如：当你的应用的部署面对分布的事务需求时，也仅仅是改变一下配置的事。只要简单地将Hibernate的事务管理换为JTA事务实现即可。所有的事务划分和数据访问无需做任何变动仍可以继续工作，因为他们使用的都是普通的事务管理API。
       对于分布式的事务会跨越多个Hibernate的session factories，仅仅是联合JtaTransactionManager与多个LocalSessionFactoryBean定义作为事务策略。你的每一个DAO将通过它们各自的Bean属性得到一个特殊的SessionFactory的引用。如果这一切都是在下面的JDBC数据源是事务容器，一个业务对象可以划分事务跨越很多DAO和很多session factories而无需做特别的处理，对于使用JtaTransactionManager做为事务策略也是一样的。

 
<beans>

<bean id="myDataSource1" class="org.springframework.jndi
.JndiObjectFactoryBean">
<property name="jndiName">
<value>jdbc/myds1</value>
</property>
</bean>

<bean id="myDataSource2" class="org.springframework.jndi.
JndiObjectFactoryBean">
<property name="jndiName">
<value>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的在JVM层次的缓存处理-不需要容器-提供特殊的事务查找或者JCA连接器（只要不使用EJB发起事务）。另外，HibernateTransactionManager能输出JDBC连接供通常的JDBC访问代码使用。这样就允许在高层次上的事务划分是混合了Hibernate与JDBC而不要JTA的，只要只是访问一个数据库就可以！

8. 使用Spring管理应用的Bean

        一个Spring应用配置定义可以被多种配置实现所加载，从FileSystemXmlApplicationContext和ClassPathXmlApplicationContext到XmlWebApplicationContext。这就允许在各种环境下重用Spring管理的数据访问和业务对象。默认情况下，一个Web应用将有它自己的定义在“WEB-INF/applicationContext.xml”中的根配置。
       在任何一个Spring应用中，一个应用配置定义在一个XML格式的文件中用来对应用的所有有关的Bean进行装配，从Hibernate的session factory到自定义的数据访问和业务对象（象上面所有的Bean那样）。他们中的大多数不需要Spring容器知道他们，甚至即使是与其他Bean合作时也一样，因为他们只是简单的JavaBean之间的协作。下面的Bean定义可能是一个Spring Web 的MVC配置中用来访问业务对象的配置的一部分。

 
<bean id="myProductList" class="product.ProductListController">
<property name="productService">
<ref bean="myProductService"/>
</property>
</bean>

      Spring的Web控制器经由Bean引用拥有它们需要的所有的业务和数据访问对象，因此它们无需在应用配置中做任何手工的Bean查找。但是当使用Spring管理的Beans用于Struts或者是在EJB实现，或者一个applet中时常常是需要必须手工查找一个Bean的。因此Spring的Bean可以被用在任何地方。也许只是需要是一应用配置的引用，或者经由一个web容器的Servlet配置属性，或者从一个文件中或者类路径的资源中创建它。

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");

9. 容器资源VS本地资源

       Spring的资源管理允许简单地在一个JNDI SessionFactory和一个本地SessionFactory间做选择，同样允许在一个JNDI DataSource与本地DataSource间做选择，而无需改变应用的一行代码。在容器中保存资源定义还是在应用本地保存，主要是一个事务策略方面的事。比较一个Spring定义的本地SessionFactory与一个手工注册的JNDI SessionFactory没有任何益处。如果经由Hibernate的JCA连接器注册，才会有加入JTA事务的明显益处，特别是对EJB。

       一个重要的Spring事务提供的好处是它不与任何容器绑定。定义包括JTA在内的策略，它都可以独立工作或者在一个试验环境中工作。特别是对典型的一个数据库的事务来说，对于JTA这是一个非常轻量的和强大的选择。当使用本地EJB SLSB的事务时，你将同时依赖EJB容器和JTA-即使你只是访问一个数据库，即使只是使用SLSBs经由CMT来声明事务。选择使用 JTA编程也需要一个J2EE环境。

       就JTA自身和JNDI数据源来说JTA不只是包括容器依赖。对于不使用Spring的JTA驱动的Hibernate事务，你必须使用HibernateJCA连接器或者在合适的JVM缓冲层专门写Hibernate的事务代码配置JTA事务。在只访问一个数据库的情况下，Spring驱动的事务可以与一个本地定义的Hibernate的SessionFactory配合良好，就如同与一个本地JDBC数据源相配合一样。因此当面对分布的事务需求时，你只需要转换为Spring的JTA事务策略即可。

       要注意一个JCA连接器需要特别的容器的部署步骤，并且显然首先得支持JCA。这比使用本地资源定义和Spring驱动事务来部署一个简单的Web应用有更多的争议。而且你常常需要企业版本的容器支持，象WebLogic Express就不提供JCA。一个只用一个数据库的使用本地资源和事务的Spring应用可以在任何J2EE的Web容器中工作，Web容器不必支持JTA, JCA和EJB，如：Tomcat, Resin甚至最小的Jetty。另外，这样一个中间层就可以很容易地在桌面应用或者在测试套件中被重用。

       所有考虑过的事情包括：如果你不使用EJB，坚持使用本地SessionFactory，使用SpringHibernateTransactionManager或者JtaTransactionManager，你将获得包括适当处理的JVM层的缓存和分布事务的所有益处，而无需引起任何关于容器部署的争论。经由JCA连接器的一个Hibernate的SessionFactory的JNDI注册只是在使用EJB的情况中才会有明显的附加值。

10. Skeletons和例子

      配置使用Spring和HIbernate的一个J2EE的Web应用的注释和细节最好去看看在Spring Framework的例子中的“典型的Web应用”Skeletons，它给出了适合于JDBC 和 Hibernate应用的多种数据源及事务管理的配置项，仔细看一下事务拦截器的配置，它也同样向你展示了如何配置AOP拦截器。

      在Spring的1.0 M2版中，例子Petclinic提供了JDBC和Hibernate的DAO实现和应用配置的选择。Petclinic
可以作为一个可工作的简单应用说明如何在一个Spring web 应用中使用Hibernate，同样也包括根据不同的事务策略来声明事务划分。

Links

Spring Framework website

Spring Framework documentation