[转]Spring中WebApplicationContext的研究

　　本文是一篇关于DAO设计模式的入门文章，突出讲述了它的优点和不足之处。另外，本文还介绍了Spring 2.0 JDBC/DAO框架并示范了它如何妥善地解决传统DAO设计中的缺陷。

　　传统的DAO设计

　　数据访问对象（DAO）是一个集成层设计模式，如Core J2EE Design Pattern 图书所归纳。它将持久性存储访问和操作代码封装到一个单独的层中。本文的上下文中所提到的持久存储器是一个RDBMS.

　　这一模式在业务逻辑层和持久存储层之间引入了一个抽象层，如图1所示。业务对象通过数据访问对象来访问RDBMS（数据源）。抽象层改善了应用程序代码并引入了灵活性。理论上，当数据源改变时，比如更换数据库供应商或是数据库的类型时，仅需改变数据访问对象，从而把对业务对象的影响降到最低。

　　图1. 应用程序结构，包括DAO之前和之后的部分

　　讲解了DAO设计模式的基础知识，下面将编写一些代码。下面的例子来自于一个公司域模型。简而言之，这家公司有几位员工工作在不同的部门，如销售部、市场部以及人力资源部。为了简单起见，我们将集中讨论一个称作“雇员”的实体。

　　针对接口编程

　　DAO设计模式带来的灵活性首先要归功于一个对象设计的最佳实践：针对接口编程（P2I）。这一原则规定实体必须实现一个供调用程序而不是实体自身使用的接口。因此，可以轻松替换成不同的实现而对客户端代码只产生很小的影响。

　　我们将据此使用findBySalaryRange（）行为定义Employee DAO接口，IEmployeeDAO.业务组件将通过这个接口与DAO交互：

　　提供DAO实现类

　　接口已经定义，现在必须提供Employee DAO的具体实现，EmployeeDAOImpl：

　　它们封装了所有与JDBC API的交互。如果使用像Kodo或者Hibernate的O/R映射方案，则DAO类可以将这些产品的私有API打包。

　　它们将检索到的数据打包到一个与JDBC API无关的传输对象中，然后将其返回给业务层作进一步处理。

　　它们实质上是无状态的。唯一的目的是访问并更改业务对象的持久数据。

　　在这个过程中，它们像SQLException一样捕获任何底层JDBC API或数据库报告的错误（例如，数据库不可用、错误的SQL句法）。DAO对象再次使用一个与JDBC无关的自定义运行时异常类DBException，通知业务对象这些错误。

　　它们像Connection和PreparedStatement对象那样，将数据库资源释放回池中，并在使用完ResultSet游标之后，将其所占用的内存释放。

　　因此，DAO层将底层的数据访问API抽象化，为业务层提供了一致的数据访问API.

　　构建DAO工厂

　　DAO工厂是典型的工厂设计模式实现，用于为业务对象创建和提供具体的DAO实现。业务对象使用DAO接口，而不用了解实现类的具体情况。DAO工厂带来的依赖反转（dependency inversion）提供了极大的灵活性。只要DAO接口建立的约定未改变，那么很容易改变DAO实现（例如，从straight JDBC实现到基于Kodo的O/R映射），同时又不影响客户的业务对象：

　　与业务组件的协作

　　现在该了解DAO怎样适应更复杂的情形。如前几节所述，DAO与业务层组件协作获取和更改持久业务数据。下面的清单展示了业务服务组件及其与DAO层的交互：

　　交互过程十分简洁，完全不依赖于任何持久性接口（包括JDBC）。

问题

　　DAO设计模式也有缺点：

　　代码重复：从EmployeeDAOImpl清单可以清楚地看到，对于基于JDBC的传统数据库访问，代码重复（如上面的粗体字所示）是一个主要的问题。一遍又一遍地写着同样的代码，明显违背了基本的面向对象设计的代码重用原则。它将对项目成本、时间安排和工作产生明显的副面影响。

　　耦合：DAO代码与JDBC接口和核心collection耦合得非常紧密。从每个DAO类的导入声明的数量可以明显地看出这种耦合。

　　资源耗损：依据EmployeeDAOImpl类的设计，所有DAO方法必须释放对所获得的连接、声明、结果集等数据库资源的控制。这是危险的主张，因为一个编程新手可能很容易漏掉那些约束。结果造成资源耗尽，导致系统停机。

　　错误处理：JDBC驱动程序通过抛出SQLException来报告所有的错误情况。SQLException是检查到的异常，所以开发人员被迫去处理它，即使不可能从这类导致代码混乱的大多数异常中恢复过来。而且，从SQLException对象获得的错误代码和消息特定于数据库厂商，所以不可能写出可移植的DAO错误发送代码。

　　脆弱的代码：在基于JDBC的DAO中，两个常用的任务是设置声明对象的绑定变量和使用结果集检索数据。如果SQL where子句中的列数目或者位置更改了，就不得不对代码执行更改、测试、重新部署这个严格的循环过程。

　　让我们看看如何能够减少这些问题并保留DAO的大多数优点。

　　进入Spring DAO

　　先识别代码中发生变化的部分，然后将这一部分代码分离出来或者封装起来，就能解决以上所列出的问题。Spring的设计者们已经完全做到了这一点，他们发布了一个超级简洁、健壮的、高度可伸缩的JDBC框架。固定部分（像检索连接、准备声明对象、执行查询和释放数据库资源）已经被一次性地写好，所以该框架的一部分内容有助于消除在传统的基于JDBC的DAO中出现的缺点。

　　图2显示的是Spring JDBC框架的主要组成部分。业务服务对象通过适当的接口继续使用DAO实现类。JdbcDaoSupport是JDBC数据访问对象的超类。它与特定的数据源相关联。Spring Inversion of Control （IOC）容器或BeanFactory负责获得相应数据源的配置详细信息，并将其与JdbcDaoSupport相关联。这个类最重要的功能就是使子类可以使用JdbcTemplate对象。

　　图2. Spring JDBC框架的主要组件

　　JdbcTemplate是Spring JDBC框架中最重要的类。引用文献中的话：“它简化了JDBC的使用，有助于避免常见的错误。它执行核心JDBC工作流，保留应用代码以提供SQL和提取结果。”这个类通过执行下面的样板任务来帮助分离JDBC DAO代码的静态部分：

　　从数据源检索连接。

　　准备合适的声明对象。

　　执行SQL CRUD操作。

　　遍历结果集，然后将结果填入标准的collection对象。

　　处理SQLException异常并将其转换成更加特定于错误的异常层次结构。

　　利用Spring DAO重新编写

　　既然已基本理解了Spring JDBC框架，现在要重新编写已有的代码。下面将逐步讲述如何解决前几节中提到的问题。

　　第一步：修改DAO实现类- 现在从JdbcDaoSupport扩展出EmployeeDAOImpl以获得JdbcTemplate.

　　在上面的清单中，传入参数映射中的值存储在双字节数组中，顺序与SQL字符串中的位置参数相同。queryForList（）方法以包含Map（用列名作为键，一项对应一列）的List（一项对应一行）的方式返回查询结果。稍后我会说明如何返回传输对象列表。

　　从简化的代码可以明显看出，JdbcTemplate鼓励重用，这大大削减了DAO实现中的代码。JDBC和collection包之间的紧密耦合已经消除。由于JdbcTemplate方法可确保在使用数据库资源后将其按正确的次序释放，所以JDBC的资源耗损不再是一个问题。

　　另外，使用Spring DAO时，不必处理异常。JdbcTemplate类会处理SQLException，并根据SQL错误代码或错误状态将其转换成特定于Spring异常的层次结构。例如，试图向主键列插入重复值时，将引发DataIntegrityViolationException.然而，如果无法从这一错误中恢复，就无需处理该异常。因为Spring DAO的根异常类DataAccessException是运行时异常类，所以可以这样做。值得注意的是Spring DAO异常独立于数据访问实现。如果实现是由O/R映射解决方案提供，就会抛出同样的异常。

第二步：修改业务服务- 现在业务服务实现了一个新方法setDao（），Spring容器使用该方法传递DAO实现类的引用。该过程称为“设置方法注入（setter injection）”，通过第三步中的配置文件告知Spring容器该过程。注意，不再需要使用DAOFactory，因为Spring BeanFactory提供了这项功能：

　　请注意P2I的灵活性；即使极大地改动DAO实现，业务服务实现也只需少量更改。这是由于业务服务现在由Spring容器进行管理。

　　第三步：配置Bean Factory- Spring bean factory需要一个配置文件进行初始化并启动Spring框架。这个配置文件包含所有业务服务和带Spring bean容器的DAO实现类。除此之外，它还包含用于初始化数据源和JdbcDaoSupport的信息：

　　这个Spring bean容器通过调用JdbcDaoSupport提供的setDataSource（）方法，设置包含DAO实现的数据源对象。

　　第四步：测试- 最后是编写JUnit测试类。依照Spring的方式，需要在容器外部进行测试。然而，从第三步中的配置文件可以清楚地看到，我们一直在使用WebLogic Server连接池。

使用绑定变量

　　到目前为止，我们搜索了工资介于最低值和最高值之间的雇员。假设在某种情形下，业务用户想要颠倒这一范围。DAO代码很脆弱，将不得不通过更改来满足要求的变化。这个问题在于使用了静态的位置绑定变量（用“？”表示）。Spring DAO通过支持命名的绑定变量来挽救这个情况。修改的IEmployeeDAO清单引入了命名的绑定变量（用“：<some name>”表示）。注意查询中的变化，如下所示：

　　多数JDBC驱动程序仅支持位置绑定变量。所以，Spring DAO在运行时将这个查询转换成位置绑定、基于变量的查询，并且设置正确的绑定变量。现在，为了完成这些任务，需要使用NamedParameterJdbcDaoSupport类和NamedParameterJdbcTemplate类，以代替JdbcDaoSupport和JdbcTemplate.下面就是修改后的DAO实现类：

　　NamedParameterJdbcDaoSupport的getNamedParameterJdbcTemplate（）方法返回一个NamedParameterJdbcTemplate实例，该实例由数据源句柄进行了预初始化。Spring Beanfactory执行初始化任务，从配置文件获得所有的详细信息。在执行时，一旦将命名的参数替换成位置占位符，NamedParameterJdbcTemplate就将操作委托给JdbcTemplate.可见，使用命名的参数使得DAO方法不受底层SQL声明任何更改的影响。

　　最后，如果数据库不支持自动类型转换，需要如下所示，对JUnit测试类中的initSalaryMap（）方法稍做修改。

　　至此，已经说明为了解决传统DAO设计中存在的问题，如何封装和概括JdbcTemplate类中JDBC代码的静态部分。现在了解一下有关变量的问题，如设置绑定变量、结果集遍历等。虽然Spring DAO已经拥有这些问题的一般化解决方案，但在某些基于SQL的情况下，可能仍需要设置绑定变量。

　　在尝试向Spring DAO转换的过程中，介绍了由于业务服务及其客户机之间的约定遭到破坏而导致的隐蔽运行时错误。这个错误的来源可以追溯到原始的DAO.dbcTemplate.queryForList（）方法不再返回EmployeeTO实例列表。而是返回一个map表（每个map是结果集的一行）。

　　如您目前所知，JdbcTemplate基于模板方法设计模式，该模式利用JDBC API定义SQL执行工作流。必须改变这个工作流以修复被破坏的约定。第一个选择是在子类中更改或扩展工作流。您可以遍历JdbcTemplate.queryForList（）返回的列表，用EmployeeTO实例替换map对象。然而，这会导致我们一直竭力避免的静态代码与动态代码的混合。第二个选择是将代码插入JdbcTemplate提供的各种工作流修改钩子（hook）。明智的做法是在一个不同的类中封装传输对象填充代码，然后通过钩子链接它。填充逻辑的任何修改将不会改变DAO.

　　编写一个类，使其实现在Spring框架特定的接口中定义的方法，就可以实现第二个选择。这些方法称为回调函数，通过JdbcTemplate向框架注册。当发生相应的事件（例如，遍历结果集并填充独立于框架的传输对象）时，框架将调用这些方法。

　　第一步：传输对象

　　下面是您可能感兴趣的传输对象。注意，以下所示的传输对象是固定的：

　　第二步：实现回调接口

　　实现RowMapper接口，填充来自结果集的传输对象。下面是一个例子：

　　注意实现类不应该对提供的ResultSet对象调用next（）方法。这由框架负责，该类只要从结果集的当前行提取值就行。回调实现抛出的任何SQLException也由Spring框架处理。

　　第三步：插入回调接口

　　执行SQL查询时，JdbcTemplate利用默认的RowMapper实现产生map列表。现在需要注册自定义回调实现来修改JdbcTemplate的这一行为。注意现在用的是NamedParameterJdbcTemplate的query（）方法，而不是queryForList（）方法：

　　Spring DAO框架对执行查询后返回的结果进行遍历。它在遍历的每一步调用EmployeeTOMapper类实现的mapRow（）方法，使用EmployeeTO传输对象填充最终结果的每一行。

　　第四步：修改后的JUnit类

　　现在要根据返回的传输对象测试这些结果。为此要对测试方法进行修改。

　　优势

　　Spring JDBC框架的优点很清楚。我们获益很多，并将DAO方法简化到只有几行代码。代码不再脆弱，这要感谢该框架对命名的参数绑定变量的“开箱即用”支持，以及在映射程序中将传输对象填充逻辑分离。

　　Spring JDBC的优点应该促使您向这一框架移植现有的代码。希望本文在这一方面能有所帮助。它会帮助您获得一些重构工具和知识。例如，如果您没有采用P2I Extract Interface，那么可以使用重构，从现有的DAO实现类创建接口。除此之外，查看本文的参考资料可以得到更多指导。

　　源代码下载

在J2EE应用开发中，经常遇到的问题就是：如何将不同的组件组装成为一个内聚的应用程序？IoC模式可以解决这个问题，其目标是将组件的配置与使用分离开。

IoC，Inversion of Control，控制反转[1]，其原理是基于OO设计原则的The Hollywood Principle：Don't call us, we'll call you。也就是说，所有的组件[2]都是被动的（Passive），所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。

要说明IoC模式最好的方法是使用代码。下边是一段正常的代码。

class ClassA...

  public String aMethod(String arg){

    String result = instanceOfClassB.bMethod();

    do something;

    return result;

  }

在上边的代码里，我们要解决的问题是：ClassA如何获得ClassB的实例？一个最直接的方法是在aMethod里声明：

IClassB instanceOfClassB = new ClassB();

这里使用了一个接口IClassB。

问题是，如果出现这样的情况：继续使用ClassA，但要求用IClassB的另一个实现ClassB2代替ClassB呢？更概括一点说：ClassA怎样才能找到IClassB的具体实现？很明显，上述代码增加ClassA和ClassB的耦合度，以致于无法在不修改ClassA的情况下变更IClassB的具体实现。

IoC模式就是用于解决这样的问题。当然，还有其他的方法，比如Service Locator模式，但现在我们只关注IoC。如前所述，IoC容器负责初始化组件（如IClassB），并将实例交给使用者。使用代码或配置文件以声明的方式将接口与实例关联起来，IoC容器负责进行实际的调用处理。对于调用者，只需要关注接口就行了。

根据实例传入方式的不同，IoC分为type 1 IoC（接口注入[3]）、type 2 IoC（设值方法注入）和type 3 IoC（构造子注入）。分别用代码说明如下：

type 1 IoC（接口注入）

public interface GetClassB {

  void getClassB(IClassB instanceOfClassB);

}

class ClassA implements GetClassB…

  IClassB instanceOfClassB;

  void getClassB(IClassB instanceOfClassB) {

this.instanceOfClassB = instanceOfClassB;

  }

type 2 IoC（设值方法注入）

class ClassA...

  IClassB instanceOfClassB;

  public void setFinder(IClassB instanceOfClassB) {

    this.instanceOfClassB = instanceOfClassB;

  }

type 3 IoC（构造子注入）

class ClassA…

ClassB instanceOfClassB;

  public classA(IClassB instanceOfClassB) {

    this. instanceOfClassB = instanceOfClassB;

  }

资源链接页

Spring Framework Documentaion

http://www.springframework.org/documentation.html

Spring中文论坛图书贴

http://xglw.51.net/5team/springframework/viewtopic.php?t=31

Spring Reference Documentation

http://www.springframework.org/docs/reference/index.html

or http://www.springframework.org/docs/spring-reference.pdf

作者：Spring 开发组

中文版http://xglw.51.net/5team/springframework/book/spring_referece_inchinese_m2.pdf（for M2）

翻译：Spring中文论坛翻译组

Spring的Document中还提供了：

The Spring Framework - A Lightweight Container by Rod Johnson, Juergen Hoeller

Container Resources vs Local Resources(for transactional data access with the Spring Framework) by Juergen Hoeller

Data Access and Transaction Abstraction with the Spring Framework(featuring Hibernate examples) by Juergen Hoeller

Web MVC with the Spring Framework by Juergen Hoeller

中文版：http://xglw.51.net/5team/springframework/book/webMvcSpring.pdf

翻译；yanger

（more…）

Introducing the Spring Framework

http://www.theserverside.com/articles/article.tss?l=SpringFramework

作者：Rod Johnson

中文版 http://xglw.51.net/5team/springframework/viewtopic.php?t=18

翻译：yanger

Developing a Spring Framework MVC application step-by-step

http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html

作者：Thomas Risberg

Spring Framework Tutorial

http://www.springframework.org/downloads/tutorial.pdf

作者：Isabelle Muszynski

在Spring In Chinese Group有

（PPT） On Spring by gigix

（PPT） Spring Introduction for 3.12M2 by yanger

Framework Design

http://qca.cn/frameworkdesign/content.htm

作者：林星

书籍购买链接

Expert One-on-One J2EE Design and Development

（略）

作者：Rod Johnson

中文版：http://www.china-pub.com/computers/common/info.asp?id=14126

（说明：英文版本身很简明，翻译则评价甚差）

我眼中的Spring

http://www.blogbus.com/blogbus/blog/diary.php?diaryid=125334

作者：dreamhead

 

Spring is coming

http://www.blogbus.com/blogbus/blog/diary.php?diaryid=126737

作者：founder_chen

冰河快狼 2006-03-11 08:20 发表评论

]]>

分析ApplicationContext

       Spring的bean包支持通过编码方式管理和操作bean的基本功能，ApplicationContext

则以Framework的方式提供BeanFactory的所有功能。使用ApplicationContext，你可以让

系统加载你的bean（例如，在Servlet容器初始化ContextLoaderServlet时，通过

ContextLoader类加载Spring Framework），而不是使用编码方式来加载。

       ApplicationContext接口是context包的基础，位于

org.springframework.context包里，提供了BeanFactory的所有功能。除此之外， 

ApplicationContext为了支持Framework的工作方式，提供了以下的功能：

      l.MessageSource，提供了语言信息的国际化支持
      2.提供资源（如URL和文件系统）的访问支持
      3.为实现了ApplicationListener接口的bean提供了事件传播支持
      4.为不同的应用环境提供不同的context，例如支持web应用的XmlWebApplicationContext类

      下面的源代码分析主要集中在ApplicationContext接口特有的功能上，如国际化支持，

资源访问和bean的事件传播。

我的问题

       现在我的问题是，ApplicationContext是如何实现上面提到的功能的？下面的分析

将作出回答。

准备测试用例

       1. 首先在类路径根目录编写测试国际化支持的testmsg.xml，并将它加入Spring IDE

的管理范围：

       <beans>
            <bean id="messageSource" 

           class="org.springframework.context.support.ResourceBundleMessageSource">
                 <property name="basenames">
                      <list>
                            <value>message</value>
                      </list>
                 </property>
            </bean>
       </beans>

       2. 编写测试用例，测试国际化支持和资源访问的功能。
           public class MsgTest extends TestCase {
                 ApplicationContext ctx = null;
                 public MsgTest(String arg0) {
                       super(arg0);
                 }
                 protected void setUp() throws Exception {
                       super.setUp();
                       ctx = new FileSystemXmlApplicationContext("testmsg.xml");
                 }
                 public void testMessageResource() {
                       Object[] args = {"我", "你"};
                       String msg = ctx.getMessage("hello", args, Locale.CHINA);
                       //System.out.println("msg=" + msg);
                       assertEquals("我和你", msg);
                       Resource rs = ctx.getResource("classpath:log4j.properties");
                       assertTrue(rs.exists());
                }
           }

       3. 在类路径根目录创建属性文件message.properties，内容为hello={0}和{1}。
 
       此时运行TestCase，果然不出所料，Junit视图的测试状态是红条。将打印msg变量的

语句打开，重新测试，发现"和"字是乱码。

       在message.properties文件中将"和"字改为ASCII码\u548c，重新运行TestCase，

绿条，测试通过。

       将testmsg.xml中bean的id改为messageSource1，重新运行测试，出现红条，

测试失败，说明bean的名称必须是messageSource，这点值得注意。至于其中的原因稍后

说明。

       ApplicationContext接口通过继承BeanFactory，MessageSource和ResourceLoader

三个接口，分别支持管理和操作bean的功能，语言信息的国际化支持以及对资源访问的支持。

       AbstractApplicationContect是ApplicationContext的抽象实现类，它的继承层次较

为紊乱，我觉得这里应该进行代码重构。AbstractXmlApplicationContext是

AbstractApplicationContext的子类，提供了对XML配置文件的支持，它有三个子类，分别

用于不同的应用环境。

       对于MessageSource，Spring提供了两个bean实现，ResourceBundleMessageSource和

ReloadableResourceBundleMessageSource。前者提供了访问Properties文件的支持，后者

添加了无需重启JVM，重新加载Properties文件的支持。

ApplicationContext的国际化和资源访问支持

       1. 如类层次图所示，在我们的例子中，FileSystemXmlApplicationContext使用

DefaultListableBeanFactory装载和解释testmsg.xml配置文件（参见代码分析的

BeanFactory部分）。

       2. FileSystemXmlApplicationContext根据配置文件的BeanDefinition创建

ResourceBundleMessageSource，加载<list>元素定义的Properties文件，并保存在

AbstractApplicationContext的属性中。当客户程序调用getMessage方法时，

AbstractApplicationContext调用ResourceBundleMessageSource的getMessage方法返回

Message信息。

       3. 至于上节提到的MessageSource的id只能是messageSource，是因为

AbstractApplicationContext的initMessageSource()方法中，有这样一段代码：

                   this.messageSource = (MessageSource) 
                   getBean(MESSAGE_SOURCE_BEAN_NAME);

           其中MESSAGE_SOURCE_BEAN_NAME的定义为：

                   static final String MESSAGE_SOURCE_BEAN_NAME = "messageSource";

           原因找到了，其实只要稍做代码重构，即可消除这个缺陷。

       4. 如类层次图所示，AbstractApplicationContext继承了DefaultResourceLoader，

当客户程序调用getResource方法时，使用父类中实现的方法来处理。

 
ApplicationContext的事件传播

准备测试用例

       1. 首先编写测试用例。
           public class SenderBeanTest extends TestCase {
                ApplicationContext ctx = null;
                protected void setUp() throws Exception {
                    super.setUp();
                    ctx = new FileSystemXmlApplicationContext("testlistener.xml");
                }
                public void testSendEmail() {
                    SenderBean sender = (SenderBean)ctx.getBean("sender");
                    String msg = sender.sendMessage("test message");
                    assertEquals("test message", msg);
                }
           }

       2. 接着编写testlistener.xml配置文件。
           <beans>
               <bean id="sender" class="unittest.SenderBean"/>
               <bean id="listener" class="unittest.MessageListener"/>
           </beans>

       3. 最后编写SenderBean，MessageListener和MessageEvent类。
           public class SenderBean implements ApplicationContextAware {
                  private ApplicationContext applicationContext;
                  public void setApplicationContext(ApplicationContext applicationContext)
                            throws BeansException {
                        this.applicationContext = applicationContext;
                  }
                  public String sendMessage(String msg) {
                        MessageEvent event = new MessageEvent(msg);
                        this.applicationContext.publishEvent(event);
                        return msg;
                  }
            }
 
            public class MessageListener implements ApplicationListener {
                  public void onApplicationEvent(ApplicationEvent event) {
                        if (event instanceof MessageEvent) {
                              System.out.println("I got the message:" + event.getSource());
                        }
                  }
            }
 
            public class MessageEvent extends ApplicationEvent {
                  public MessageEvent(Object source) {
                        super(source);
                        System.out.println(this.getTimestamp() + ":" + source);
                  }
            }

           运行测试案例SenderBeanTest，绿条，测试通过。Console窗口出现以下DEBUG

信息：

           ……
           796 DEBUG support.DefaultListableBeanFactory - Returning 

cached instance of singleton bean 'sender'
           1085553911796:test message
           796 DEBUG support.FileSystemXmlApplicationContext - Publishing event 

in context [org.springframework.context.support.FileSystemXmlApplicationContext;hashCode=13549765]: 

unittest.MessageEvent[source=test message]
           I got the message:test message

 
事件传播的实现
       1. FileSystemXmlApplicationContext的构造器调用AbstractApplicationContext的

refresh方法。如图所示，refresh方法调用refreshListeners方法。

       2. AbstractApplicationContext的refreshListeners方法使用BeanFactory的

getBeanOfType方法得到所有ApplicationListener类（本例中是MessageListener），并使用

addListener方法把它们都放入ApplicationEventMulticasterImpl的Set容器中

（eventListeners变量）。

       3. 如图所示，SenderBean实现ApplicationContextAware接口，并通过

setApplicationContext方法注入ApplicationContext对象实例。

       4. 当调用SenderBean类sendMessage方法时，AbstractApplicationContext调用

publishEvent方法。

       5. AbstractApplicationContext类的publishEvent方法调用

ApplicationEventMulticasterImpl类的onApplicationEvent方法。

       6. ApplicationEventMulticasterImpl通知Set容器中所有的ApplicationListener

对象，调用它们的onApplicationEvent方法。

 
       从以上的过程可以看出，ApplicationContext将事件通知所有的

ApplicationListener。如果ApplicationListener的子类（如MessageListener）只想接受

指定的事件类型，需要自己编写过滤代码，如例子中的if (event instanceof MessageEvent)。

/**
作者：Willpower
来源：Rifoo Technology（http://www.rifoo.com）
时间：2005-12-25
备注：转载请保留以上声明
**/

这本书是一个以代码和实战为主的书，全书在构建一个过山车订购系统，体育商店可以用来对它们的过山车进行管理和订购。第一节作者先硬编码了两个有依赖关系的类CommandLineView.java和RentABike.java。我们先看看源代码：

Example 1-1. Bike.java
public class Bike {
  private String manufacturer;
  private String model;
  private int frame;
  private String serialNo;
  private double weight;
  private String status;

  public Bike(String manufacturer, String model, int frame,
          String serialNo, double weight, String status) {

    this.manufacturer = manufacturer;
    this.model = model;
    this.frame = frame;
    this.serialNo = serialNo;
    this.weight = weight;
    this.status = status;
  }

  public String toString( ) {
    return "Bike : " +
          "manufacturer -- " + manufacturer +
          "\n: model -- " + model +
          "\n: frame -- " + frame +
          "\n: serialNo -- " + serialNo +
          "\n: weight -- " + weight +
          "\n: status -- " + status +
          ".\n";
  }
 
  public String getManufacturer( ) { return manufacturer; }

  public void setManufacturer(String manufacturer) {
    this.manufacturer = manufacturer;
  }

  public String getModel( ) { return model; }

  public void setModel(String model) { this.model = model; }

  public int getFrame( ) { return frame; }

  public void setFrame(int frame) { this.frame = frame; }

  public String getSerialNo( ) { return serialNo; }

  public void setSerialNo(String serialNo) { this.serialNo = serialNo; }

  public double getWeight( ) { return weight; }

  public void setWeight(double weight) { this.weight = weight; }

  public String getStatus( ) { return status; }

  public void setStatus(String status) { this.status = status; }
}

可以看出，Bike.java是一个普通的JAVABEAN，用来表述一个过山车实体，包括制造商，型号，规格，序列号，重量和状态等树型。

Example 1-2. RentABike.java
import java.util.*;
public class RentABike {

  private String storeName;
  final List bikes = new ArrayList( );

  public RentABike(String storeName) {
    this.storeName = storeName;//商店名
  //添加过山车到数组
    bikes.add(new Bike("Shimano", "Roadmaster", 20, "11111", 15,
                  "Fair"));
    bikes.add(new Bike("Cannondale", "F2000 XTR", 18, "22222",12,
                  "Excellent"));
    bikes.add(new Bike("Trek","6000", 19, "33333", 12.4,
                  "Fair"));
  }

  public String toString( ) { return "RentABike: " + storeName; }
  //得到全部过山车
  public List getBikes( ) { return bikes; }
  //得到某一个序列号的过山车
  public Bike getBike(String serialNo) {
    Iterator iter = bikes.iterator( );
    while(iter.hasNext( )) {
        Bike bike = (Bike)iter.next( );
        if(serialNo.equals(bike.getSerialNo( ))) return bike;
    }
    return null;
  }
}

这个类描叙了租用一台过山车的操作，storeName是传入的商店名称。它对客户端来说是一个门面，把所租用的过山车都放在一个List数组中存放起来，然后对外提供getBikes和getBike两个方法，可以让客户端知道目前所租用的所有过山车和某一个序列号的过山车是什么。

我们再看看用户接口是如何调用的：
Example 1-3. CommandLineView.java
import java.util.*;
public class CommandLineView {
  private RentABike rentaBike;
  public CommandLineView( ) {rentaBike = new RentABike("Bruce's Bikes"); }

  public void printAllBikes( ) {
    System.out.println(rentaBike.toString( ));
    //调用门面的方法
    Iterator iter = rentaBike.getBikes( ).iterator( );
    while(iter.hasNext( )) {
        Bike bike = (Bike)iter.next( );
        System.out.println(bike.toString( ));
    }
  }

  public static final void main(String[] args) {
    CommandLineView clv = new CommandLineView( );
    clv.printAllBikes( );
  }
}


运行结果：

C:\RentABikeApp\out> java CommandLineView

RentABike: Bruce's Bikes
Bike : manufacturer -- Shimano
: model -- Roadmaster
: frame -- 20
: serialNo -- 11111
: weight -- 15.0
: status -- Fair.

Bike : manufacturer -- Cannondale
: model -- F2000 XTR
: frame -- 18
: serialNo -- 22222
: weight -- 12.0
: status -- Excellent.

Bike : manufacturer -- Trek
: model -- 6000
: frame -- 19
: serialNo -- 33333
: weight -- 12.4
: status -- Fair.

大家看出问题了吗？
1 门面RentABike静态的创建了一个商店里的租用的过山车，所以到时候如果一个新的过山车被引入的话，那么就需要手工修改RentABike的代码，比如我们再加一个Bike2.java，属性和Bike.java不一样。我们还需要在RentABike的类里实例化它才行，这样就造成了硬编码
2 这个模型Bike.java是很难测试的，因为Bikes数组是固定的
3 这用户接口和门面之间是强耦合的，它们存在一个硬编码的依赖，大家注意CommandLineView.java中的这两行代码：
private RentABike rentaBike;
public CommandLineView( ) {rentaBike = new RentABike("Bruce's Bikes"); }

所以，这一段程序虽然能够完成一个简单的租用过山车的操作，但是却不是一个易维护和扩展的。

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

Web层的Tapestry负责数据输入输出, 响应用户事件，及输入校验的工作, 通过访问预先加载的WebApplicationContext(由Spring提供, 包含着所有Service bean)获得Service层的Service Bean, 把业务操作都委托给它们.

Service层的bean则负责use case逻辑, domain相关的逻辑委托给domain model中的bean去实现. Service通过DAO完成对domain model的持久化工作. Service负责数据库事务和Hibernate Session的管理(通过Spring的声明式事务管理和与之集成的Hibernate Session管理). Service层的另一项重要工作是权限和访问控制。

Domain model负责表示问题域的数据和domain logic. DAO使用Hibernate持久化数据以及查询. 在实现DAO时, 我们使用了Spring的Hibernate DAO Support,极大地简化了代码, 很多方法都只用简单的一行完成. 有意思的是, 最后完成的HibernateDAO的代码量居然比我写的MockDAO的代码少了一半还多

这样的架构优点很明显, 层次清晰, 各层的职责也明确, 便于分层设计与开发, 结合mock和spring的IOC, unit test也是非常容易的. 而且后台(Service, domain model and DAO)的代码不依赖于Web容器或是EJB容器的API, 移植性非常好, 同样的代码可以在Web app中使用也可在普通的Java app中使用, 只需更换UI层.

按照这个整合的构架，我们实现一个简单的实例，实现了列表分页查询和显示，数据增删改，基于Hibernate Criteria Query提供了一个比较通用的查询机制。利用Middlegen和Velocity我们可以从已经建好的数据库表结构自动生成Hibernate映射文件，实体类和DAO，极大地减少了工作量。我们还对这个小例子进行了压力测试（测试时的数据量为10万条记录），确定平台不存在性能问题。

通过这个实例我们把整个架构基本走通一遍，并总结了使用这套架构开发时适用的开发流程和需要做的工作。

困扰的问题

问题1：要不要使用DTO？
在上面的架构中我们并没有明确Service和Web层间的数据传输是如何进行的。我们讨论好久要不要使用DTO，最后的结论是不用。

使用DTO有两个主要的理由：
1、减少Web层和Service层间的方法调用，通过一个方法调用就将Web需要的数据都传给Web。
2、隔离domain model和Web层。

第一个理由在当前架构下是不成立的。因为我们的架构是集中式的，Web和Service是在同一个JVM中，它们之间的方法调用是没有EJB远程访问的巨大消耗的。
第二个理由还是需要考虑的。如果允许把domain model中的对象传给Web层，那么修改domain model，就会影响到Web层。
如果使用DTO，那么domain model实现上的变化就不会影响到Web。但是大量的变化不是domain model实现上的变化，而是domain model接口的变化，比如一个domain model的对象上添加了一个属性，而这个属性需要用户修改，那么这时候必须修改Web层，不管是不是用了DTO。
而且使用DTO，就需要维护着一大堆对象，或是它们的生成器，这是非常无聊、且容易出错的工作。
基于这些考虑，没有必要使用DTO, 直接把domain object传给Tapestry的web层，利用Tapestry提供强大的数据绑定和组件功能很方便

问题2：Entity like domain model or rich domain model?
我们使用Middlegen自动生成Hibernate映射文件，Entity类和DAO类, 但是生成的Entity只含有简单的属性和getter, setter方法。
因此我们遇到了一个问题：我们的domain model还要不要包含domain logic？如果包含，那么和自动生成工具如何结合？
虽然一个rich domain model可以减少Service中的重复代码，提高复用性。 但是如何同自动生成结合？
或许可以使用<meta>标签，生成抽象基类，我们继承这些自动生成的基类，添加业务方法。
但是单纯从结构的分离角度来考虑, domain model不应该包括复杂的domain logic, 只是作为一个data model bean, 再加上一些简单的logic, 比如addChild的同时，设置child的parent此类简单logic
而且在POJO里面塞太多业务逻辑会导致Hibernate产生你预想不到的后果。

问题3：Model driven or Data driven?
这其实是一个很无聊的问题. 采用Model driven还是Data driven的方式一直都处于热烈的讨论中。我们主要是受到Rod Johnson(Expert one-on-one J2EE Design and Development 一书的作者) 的影响，采用了Data driven的方式。先作数据库设计，生成库表，然后用Middlegen反向生成Hibernate映射文件和Entity及DAO。
但是在进入项目应用之后发现这种方法有可能会出现两个问题：
a） 数据库设计仅说明了系统要管理的静态数据，我们还是得作面向对象分析，以反映系统的动态行为。特别是当系统的业务不仅仅是简单的CRUD操作时，这个问题更严重。
b） 数据库设计为了优化性能，可能会把好几个应该是单独实体的数据放入一个实体中。这样如果直接把这种极粗粒度实体映射成Entity类，那简直是不可接受的。
面向对象的分析设计模型得到的类都是相当细粒度的。这种情况还得作面向对象的分析，明确到底这个粗粒度的大表应该映射成那几个细粒度的对象。
如果采用Model driven，则可以用AndroMDA生成domain model，Hibernate DAO，Hibernate mapping，数据库表，简单的Service和前台的Tapestry页面。
不过换个角度分析, 采用哪种设计模式只是个人习惯而已，无论是Model driven或者Data driven，对于相同的需求，2者最终的设计应该都是很类似的。
更周全的做法大概可以从2边同时考虑的，一边做Model，一边还要考虑数据库的结构， 再进行相应的调整，用下来也没有什么问题。没有用代码生成，
只是用Hibernate的Eclipse plugin (Hibernate Synchronizer)来帮我做一些code assist. 也可以用xDoclet来生成mapping文件和DDL.

问题4：Hibernate Session生命周期如何管理？
对于Hibernate Session的生命周期我们采用的是Session-per-Transaction模式，未采用Open Session in View模式。
虽然Hibernate team认为这种方法没什么不好，而且FreeRoller和Atlassian的confluence都使用了Open Session In View这种模式，但是我们对它可能产生的影响还没有很好的把握，所以暂时弃置不用。
如果Web层要访问lazy load的数据, 需要先调用Service的业务方法, 以获得数据. 不过Open Session in View模式其实并不复杂.

问题5：Use case logic 和 domain logic 如何区分？
Service负责use case logic，domain model负责domain logic。这样的划分看起来很好，实现起来就很麻烦。
如何确定什么是use case logic，什么是domain logic？
不过如果像第二个问题中最后所说, domain model里面没有什么domain logic 的话，这个问题不存在

问题6：Service粒度如何确定？
这个问题真是很烦，原先考虑使用usecase controller的方式，每个usecase对应一个Service，但是发现这样复用性太低，而且好多地方必须复用相同的功能
另一种方法是用package level service，每个package作个service，这样倒是可以重用，但是感觉太死了，不好。
回到domain model里面没有什么domain logic的情况下，Service的功能就切得很细，尽量重用，一个package可能有多个service

现在也没有什么很好的办法，只好在详细设计时根据具体情况确定需要多少个Service了。TBD.

问题7：权限如何设定？如何检查？
权限设定也是个头疼的问题。我们本想是按照use case设定权限，每个用例一个权限。在角色设定的时候直接处理的都是业务意义非常明确的权限。
但是在权限验证过程中发现了问题：如果在Service的方法中验证权限，而且这个方法在多个用例中用到（复用Service），那么这个Service的方法就需要检查多个权限; 如果每个Service方法对应一个权限, 那么权限又太细了, 不像use case权限那样代表一个完整的业务.
一种考虑是将权限控制都做在Service上，权限系统的设计理念来自于Unix操作系统的权限策略，只不过我把文件和文件夹换成了Service，把组换成了Role，此外又加了一些控制对象进去，这样实现下来功能相当的强大，而且很灵活，扩展起来很方便，增加一个Service，只需要在配置文件里面设定该Service的权限级别就行了.
时针对Service的权限是得自己写代码实现的，先是定义一个权限控制接口，然后写了一个抽象类继承该权限接口，把主要的代码实现都写好了，针对特定的Service不同的部分定义为一个抽象方法，其实该抽象方法也就是把类名传递过去而已。这样每个要实施权限控制的Service只要继承该抽象方法，然后在配置文件里面定义自己的权限级别就行了。就算以后再增加别的Service模块，也非常快捷，不需要动现有的代码
如果结合了Spring, 在Spring里面可以使用AOP的办法针对Service增加权限控制，而不需要自己手工写.
看起来手工方式还是没有上面描述的Spring控制方式优雅

额外的问题:
从问题5/6中再上升一步, 考虑一下DAO的做法.一种常见的用法是写一个通用的DAO类, 而是整个系统就一个DAO (PersistenceManager), 里面只有create, update, delete entity这3个方法。另外写一个DAO, 专门做查询 (QueryManager), 用hibernate的named query做常用的查询， 用criteria来做基于用户输入的动态查询.
criteria 和 named query其实都是hardcode，domain object attribute name改变的时候，还得记得手工去修改这些代码，unit test很难覆盖到所有的criteria search 和 named query里面的代码.
DAO是为了切换持久层API用的，准确的来说，是当你在使用JDBC来直接访问数据库的时候，由于不同的数据库的sql有差别，所以需要一个DAO来切换不同的数据库的JDBC访问代码。每个数据库的JDBC代码你都要写一套，当切换数据库的时候，就可以通过DAO来切换不同的JDBC代码实现了.
是当我们使用Hibernate的时候，除了个别情况，大部分时候是不需要考虑跨数据库问题的，Hibernate已经做的足够好了。个别情况下的代码我们也可以单独做为特例处理，因此我想不到DAO的必要性了。
如果说使用DAO是为了将来切换别的O/R Mapping的话，我觉得这个话是不现实的，毕竟每种O/R Mapping的实现方式差异还是很大的，这直接影响到整个持久层设计.
而当业务层代码是直接调用Hibernate API来操纵PO的，持久层就只剩下了简单的POJO了.
另外一种常见用法是而在业务层针对每个POJO，写一个对他的CRUD操作的Manager类. 可以参看一下Appfuse的做法.其实这等于是在完成DAOImpl应该完成的工作，只不过现在把他归到了业务层来说罢了。然后你就可以根据你的业务逻辑来写你的业务Service了
在这里，至于如何切换业务逻辑的颗粒度问题, 基于OOAD的原则，应该把无关的业务放在不同的class里面，降低类之间的耦合性，提高类的可重用度。那么根据这个原则如何切分就是一个清楚的事情了.

(以上文字整理自洛宾,QW等N人在爪哇爱死论坛上的讨论)

考虑一个Button来控制Lamp的开和关。

如下的类图，并写下了代码。

public class Button {

       private Lamp lnkLamp;

       public void poll() {

              lnkLamp.Turnon();

       }

}

但是马上发现这个设计的问题，Button类直接依赖于Lamp类，这个依赖关系意味着当Lamp类修改时，Button类会受到影响。此外，想重用Button类来控制类似与Lamp的另外一个对象则是不可能的。即Button控制Lamp，并且只能控制Lamp。

显然，我违反了“高层模块不应该依赖于底层模块，两者都应该依赖于抽象；抽象不应该依赖于具体实现，细节应该依赖于抽象” 这一原则（DIP原则）。

考虑到上述问题，自然地想到应该抽象出一个接口，来消除Button对Lamp的依赖，于是设计如下：

    这样，我们倒置了Button对Lamp的依赖关系，使得Lamp依赖于SwitchableDevice接口，SwitchableDevice并没有依赖于Button类，任何知道如何操纵该接口的对象都可以控制Lamp。同时Button不只是可以控制Lamp，还可以控制同样实现SwitchableDevice接口的如Computer、Cell Phone等等。回头想想，这种做法好像似曾相识，拍拍脑袋，哦！这不是GoF策略（Strategy）模式吗？！正是，不经意间我就应用了设计模式（有点得意哦~~~~）。

现在再来考虑一个问题，刚才的做法虽然倒置了依赖关系，但是如果将Button作为一个应用程序来控制Lamp或者同样实现SwitchableDevice的Computer、Cell Phone等，则代码可能如下：

public class Button {

private SwitchableDevice lnkLamp;

public Button(){

    lnkLamp= new Lamp();

}

…

}

也就是说Button和Lamp之间仍然存在《creates》这样的依赖关系。

为了解除这种依赖关系，首先看GoF能作些什么。显然，这个地方应该用Factory模式，将对象的创建交给Factory Class来处理，这样虽然解开了Lamp组件与我们应用程序Button之间的耦合关系，但是组件的创建仍然是显式的（explicitly），在组件更改时仍需要重新编译。

另外，通过一个ServiceLocator去look up实现类也是一种解除耦合的办法，看到这儿，你不禁会想EJB不就是这么实现的嘛，U are Right! Rod Johnson 在其大作J2EE without EJB中称这种方式为Dependency Look up，但这种方式也有其弊端，比如无法脱离容器环境，以及不利于Unit test等。

“Don’t Call us, We will Call you”，这个原则启示我们应该换一个思路，不应该在应用类中创建具体对象的实例，而是应该将具体对象实例的创建插入(plug)或者说注射（inject）到应用类中，这大概是依赖注射名称的由来吧。

这种实现方式需要在应用类以及调用组件之间建立一个assembler来解除两者之间的依赖，看起来与前面的方式没有太大区别，来看一下结构：

    仔细查看会发现还是有比较大的不同，依赖关系是相反的，也就是说这个过程中依然倒置了依赖关系。Lamp通过Assembler将其创建过程注射到了Button中，从而消除了两者之间的耦合，增加了灵活性。

下面我们看一下具体的实现，在PicoContainer以及Spring中有着其不同的实现，分别代表了两种类型的Dependency Injection, 即Constructor Injection 和Setter Injection。

private MutablePicoContainer configureContainer() {

        MutablePicoContainer pico = new DefaultPicoContainer();

        pico.registerComponentImplementation(SwitchableDevice.class, Lamp.class);

        pico.registerComponentImplementation(Button.class);

        return pico;

}

然后可以通过MutablePicoContainer的getComponentImplementation方法获得实现类，调用其poll方法控制Lamp的开关，这样一来，两者之间的耦合通过PicoContainer提供的Assembler完全消除了。

Spring则通过一个XML格式的配置文件，将两者联系起来，使用时，通过ApplicationContext获得Button Bean，再调用其方法实现，同样也消除了耦合关系

最近项目使用Acegi作为安全框架的实现,效果不错,就写了这篇文章作为总结.

对于任何一个完整的应用系统，完善的认证和授权机制是必不可少的。在基于SpringFramework的WEB应用中，
我们可以使用Acegi作为安全架构的实现。本文将介绍如何在基于Spring构架的Web应用中使用Acegi，并且详细介
绍如何配置和扩展Acegi框架以适应实际需要。

文章和代码下载:

http://www.blogjava.net/Files/youlq/Acegi.zip


注意：许多朋友在部署上遇到一些麻烦，所以我将可以部署的完整的war文件传上来，注意：java代码在acegi-sample.war\WEB-INF 目录下，例子需要Mysql，建库脚本在acegi-sample.war\db目录下。

acegi-sample.part1.rar
acegi-sample.part2.rar
acegi-sample.part3.rar
acegi-sample.part4.rar

附注：

有些朋友询问我如何部署文中的例子，在此再次说明一下（文章中已经有提到）：

Mysql的建表脚本在db目录下
为了减小体积，已经将WEB-INF\lib下的依赖包删除，请自行下载以下包，并拷贝至WEB-INF\lib下：
spring-1.2.4.jar
acegi-security-0.8.3.jar
aopalliance-1.0.jar
c3p0-0.9.0.jar
commons-logging-1.0.4.jar
ehcache-1.1.jar
log4j-1.2.8.jar
mysql-connector-java-3.1.10-bin.jar
oro-2.0.8.jar

提示：
acegi-security-0.8.3.jar
aopalliance-1.0.jar
c3p0-0.9.0.jar
commons-logging-1.0.4.jar
ehcache-1.1.jar
log4j-1.2.8.jar
oro-2.0.8.jar
可以在acegi-security-0.8.3.zip所带的acegi-security-sample-contacts-filter.war中找到。
spring-1.2.4.jar
mysql-connector-java-3.1.10-bin.jar
要分别到springframework和mysql网站下载。

       Acegi安全系统，是一个用于Spring Framework的安全框架，能够和目前流行的Web容器无缝集成。它使用了Spring的方式提供了安全和认证安全服务，包括使用Bean Context，拦截器和面向接口的编程方式。因此，Acegi安全系统能够轻松地适用于复杂的安全需求。
       安全涉及到两个不同的概念，认证和授权。前者是关于确认用户是否确实是他们所宣称的身份。授权则是关于确认用户是否有允许执行一个特定的操作。
       在Acegi安全系统中，需要被认证的用户，系统或代理称为"Principal"。Acegi安全系统和其他的安全系统不同，它并没有角色和用户组的概念。

Acegi系统设计

  关键组件

      Acegi安全系统包含以下七个关键的功能组件：
         l Authentication对象，包含了Principal，Credential和Principal的授权信息。同时还可以包含关于发起认证请求的客户的其他信息，如IP地址。
        2 ContextHolder对象，使用ThreadLocal储存Authentication对象的地方。
        3 AuthenticationManager，用于认证ContextHolder中的Authentication对象。
        4 AccessDecissionManager，用于授权一个特定的操作。
        5 RunAsManager，当执行特定的操作时，用于选择性地替换Authentication对象。
        6 Secure Object拦截器，用于协调AuthenticationManager，AccessDecissionManager，RunAsManager和特定操作的执行。
        7 ObjectDefinitionSource，包含了特定操作的授权定义。

      这七个关键的功能组件的关系如下图所示（图中灰色部分是关键组件）：

  安全管理对象

       Acegi安全系统目前支持两类安全管理对象。
       第一类的安全管理对象管理AOP Alliance的MethodInvocation，开发人员可以用它来保护Spring容器中的业务对象。为了使Spring管理的Bean可以作为MethodInvocation来使用，Bean可以通过ProxyFactoryBean和BeanNameAutoProxyCreator来管理，就像在Spring的事务管理一样使用。
       第二类是FilterInvocation。它用过滤器（Filter）来创建，并简单地包装了HTTP的ServletRequest，ServletResponse和FilterChain。FilterInvocation可以用来保护HTTP资源。通常，开发人员并不需要了解它的工作机制，因为他们只需要将Filter加入web.xml，Acegi安全系统就可以工作了。

  安全配置参数

       每个安全管理对象都可以描述数量不限的各种安全认证请求。例如，MethodInvocation对象可以描述带有任意参数的任意方法的调用，而FilterInvocation可以描述任意的HTTP URL。
       Acegi安全系统需要记录应用于每个认证请求的安全配置参数。例如，对于BankManager.getBalance（int accountNumber）方法和BankManager.approveLoan（int applicationNumber）方法，它们需要的认证请求的安全配置很不相同。
       为了保存不同的认证请求的安全配置，需要使用配置参数。从实现的视角来看，配置参数使用ConfigAttribute接口来表示。Acegi安全系统提供了ConfigAttribute接口的一个实现，SecurityConfig，它把配置参数保存为一个字符串。
       ConfigAttributeDefinition类是ConfigAttribute对象的一个简单的容器，它保存了和特定请求相关的ConfigAttribute的集合。
       当安全拦截器收到一个安全认证请求时，需要决定应用哪一个配置参数。换句话说，它需要找出应用于这个请求的ConfigAttributeDefinition对象。这个查找的过程是由ObjectDefinitionSource接口来处理的。这个接口的主要方法是public ConfigAttributeDefinition getAttributes(Object object)，其中Object参数是一个安全管理对象。因为安全管理对象包含有认证请求的详细信息，所以ObjectDefinitionSource接口的实现类可以从中获得所需的详细信息，以查找相关的ConfigAttributeDefiniton对象。

  Acegi如何工作

       为了说明Acegi安全系统如何工作，我们设想一个使用Acegi的例子。通常，一个安全系统需要发挥作用，它必须完成以下的工作：
       l 首先，系统从客户端请求中获得Principal和Credential；
      2 然后系统认证Principal和Credential信息；
      3 如果认证通过，系统取出Principal的授权信息；
      4 接下来，客户端发起操作请求；
      5 系统根据预先配置的参数检查Principal对于该操作的授权；
      6 如果授权检查通过则执行操作，否则拒绝。

      那么，Acegi安全系统是如何完成这些工作的呢？首先，我们来看看Acegi安全系统的认证和授权的相关类图：

       图中绿色部分是安全拦截器的抽象基类，它包含有两个管理类，AuthenticationManager和AccessDecisionManager，如图中灰色部分。AuthenticationManager用于认证ContextHolder中的Authentication对象（包含了Principal，Credential和Principal的授权信息）；AccessDecissionManager则用于授权一个特定的操作。
      下面来看一个MethodSecurityInterceptor的例子：
      <bean id="bankManagerSecurity"
                     class="net.sf.acegisecurity.intercept.method.MethodSecurityInterceptor">
             <property name="validateConfigAttributes">
                    <value>true</value>
            </property>
            <property name="authenticationManager">
                   <ref bean="authenticationManager"/>
            </property>
            <property name="accessDecisionManager">
                  <ref bean="accessDecisionManager"/>
            </property>
            <property name="objectDefinitionSource">
                  <value>
                     net.sf.acegisecurity.context.BankManager.delete*=
                             ROLE_SUPERVISOR,RUN_AS_SERVER
                     net.sf.acegisecurity.context.BankManager.getBalance=
                             ROLE_TELLER,ROLE_SUPERVISOR,BANKSECURITY_CUSTOMER,RUN_
                  </value>
            </property>
      </bean>

      上面的配置文件中，MethodSecurityInterceptor是AbstractSecurityInterceptor的一个实现类。它包含了两个管理器，authenticationManager和accessDecisionManager。这两者的配置如下：

      <bean id="authenticationDao" class="net.sf.acegisecurity.providers.dao.jdbc.JdbcDaoImpl">
               <property name="dataSource"><ref bean="dataSource"/></property>
      </bean>
      <bean id="daoAuthenticationProvider"
                     class="net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider">
               <property name="authenticationDao"><ref bean="authenticationDao"/></property>
      </bean>
      <bean id="authenticationManager" class="net.sf.acegisecurity.providers.ProviderManager">
               <property name="providers">
                      <list><ref bean="daoAuthenticationProvider"/></list>
               </property>
      </bean>

      <bean id="roleVoter" class="net.sf.acegisecurity.vote.RoleVoter"/>
      <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>

       准备工作做好了，现在我们来看看Acegi安全系统是如何实现认证和授权机制的。以使用HTTP BASIC认证的应用为例子，它包括下面的步骤：
       1. 用户登录系统，Acegi从acegisecurity.ui子系统的安全拦截器（如BasicProcessingFilter）中得到用户的登录信息（包括Principal和Credential）并放入Authentication对象，并保存在ContextHolder对象中；
       2. 安全拦截器将Authentication对象交给AuthenticationManager进行身份认证，如果认证通过，返回带有Principal授权信息的Authentication对象。此时ContextHolder对象的Authentication对象已拥有Principal的详细信息；
       3. 用户登录成功后，继续进行业务操作；
       4. 安全拦截器（bankManagerSecurity）收到客户端操作请求后，将操作请求的数据包装成安全管理对象（FilterInvocation或MethodInvocation对象）；
       5. 然后，从配置文件（ObjectDefinitionSource）中读出相关的安全配置参数ConfigAttributeDefinition；
       6. 接着，安全拦截器取出ContextHolder中的Authentication对象，把它传递给AuthenticationManager进行身份认证，并用返回值更新ContextHolder的Authentication对象；
       7. 将Authentication对象，ConfigAttributeDefinition对象和安全管理对象（secure Object）交给AccessDecisionManager，检查Principal的操作授权；
       8. 如果授权检查通过则执行客户端请求的操作，否则拒绝；

  AccessDecisionVoter

       注意上节的accessDecisionManager是一个AffirmativeBased类，它对于用户授权的投票策略是，只要通过其中的一个授权投票检查，即可通过；它的allowIfAllAbstainDecisions属性值是false，意思是如果所有的授权投票是都是弃权，则通不过授权检查。
       Acegi安全系统包括了几个基于投票策略的AccessDecisionManager，上节的RoleVoter就是其中的一个投票策略实现，它是AccessDecisionVoter的一个子类。AccessDecisionVoter的具体实现类通过投票来进行授权决策，AccessDecisionManager则根据投票结果来决定是通过授权检查，还是抛出AccessDeniedException例外。
       AccessDecisionVoter接口共有三个方法：
public int vote(Authentication authentication, Object object, ConfigAttributeDefinition config);
public boolean supports(ConfigAttribute attribute);
public boolean supports(Class clazz);
       其中的vote方法返回int返回值，它们是AccessDecisionVoter的三个静态成员属性：ACCESS_ABSTAIN,，ACCESS_DENIED和ACCESS_GRANTED，它们分别是弃权，否决和赞成。
       Acegi安全系统中，使用投票策略的AccessDecisionManager共有三个具体实现类：AffirmativeBased、ConsensusBased和UnanimousBased。它们的投票策略是，AffirmativeBased类只需有一个投票赞成即可通过；ConsensusBased类需要大多数投票赞成即可通过；而UnanimousBased类需要所有的投票赞成才能通过。
       RoleVoter类是一个Acegi安全系统AccessDecisionVoter接口的实现。如果ConfigAttribute以ROLE_开头，RoleVoter则进行投票。如果GrantedAuthority的getAutority方法的String返回值匹配一个或多个以ROLE_开头的ConfigAttribute，则投票通过，否则不通过。如果没有以ROLE_开头的ConfigAttribute，RoleVoter则弃权。

安全拦截器

  拦截器如何工作
  MethodInvocation拦截器
  FilterInvocation拦截器

认证

  认证请求
  认证管理器
  Authentication Provider

授权

  Access Decision Manager
  Voting Decision Manager
  授权管理推荐

ContextHolder的用户接口

  用户接口目标
  HTTP会话认证
  HTTP Basic认证

这两天根据夏昕的Spring开发指南，在加上自己参考其他资料，做出了一个利用Spring的MVC，加上Hibernate的网站的实例，包括Jsp界面表单的提交，Spring的 MVC控制，使用Spring提供的HibernateTemplate进行数据持久的完整例子.

下面把程序的详细代码贴出来，由于自己也是初学，有不对的地方，还请过路的大侠指点一二。

一、需求：表单填写用户ID，用户名和地址，写入数据库

二、具体实现。。。。  代码见详细内容

网上讲Spring的资料很多，大部分实例都是针对Spring的某一部分做出的例子，如Ioc,Aop,MVC,数据持久层等等，没有一个完整的例子。

这两天根据夏昕的Spring开发指南，在加上自己参考其他资料，做出了一个利用Spring的MVC，加上Hibernate的网站的实例，包括Jsp界面表单的提交，Spring的 MVC控制，使用Spring提供的HibernateTemplate进行数据持久的完整例子.

下面把程序的详细代码贴出来，自己也是初学，有不对的地方，还请过路的大侠指点一二。

一、需求：表单填写用户ID，用户名和地址，写入数据库

二、具体实现

1.UserInfoAdd.jsp

填写表单界面，输入ID,Name,Address后提交到UserInfoAddAction.do

UserID:Name: Address:

2.UserInfoVO 

表单的映射。 Value Object类，用来获取表单提交的数据

3.UserInfoAddAction

Control类，根据Spring的配置文件，调用合适的接口，执行业务操作，控制页面转向。如果添加数据成功，就重定向到成功页面，如果失败，就装到操作失败页面。具体调用的操作类，是根据Spring的配置文件来找的。使用的是接口操作，而不是实现类的操作。

4.UserInfo

PO类，数据model层的反映，与数据库建立O/R mapping的映射

5.UserInfo.hbm.xml

PO的hibernate O/R mapping定义文件，这里的ID我设置成了assigned程序获取

6.UserInfoDAO

接口类，只定义了实现方法名称

7.UserInfoDAOImp

UserInfoDAO接口的实现，继承了HibernateDaoSupport

8.Web.xml的配置

9.Config.xml的定义

"http://www.springframework.org/dtd/spring-beans.dtd">      class="org.springframework.web.servlet.view.InternalResourceViewResolver">       org.springframework.web.servlet.view.JstlView                    .jsp           class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">            UserInfoAddAction               class="com.kacakong.spring.action.UserInfoAddAction">       com.kacakong.spring.vo.UserInfoVO          fail          UserInfo

10.Hibernate-Context.xml的定义

下面是要引入的JAR包
    <classpathentry kind="lib" path="D:/classes/spring.jar"/>
    <classpathentry kind="lib" path="D:/classes/junit-3.8.1.jar"/>
    <classpathentry kind="lib" path="D:/classes/spring-dao.jar"/>
    <classpathentry kind="lib" path="D:/classes/mysql-connector-java-3.0.9-stable-bin.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-dbcp-1.1.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-pool-1.1.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-collections.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-beanutils.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-lang-2.0.jar"/>
    <classpathentry kind="lib" path="D:/classes/commons-logging-1.0.3.jar"/>

SpringDao.java文件

package com.bcxy.spring.dao;

import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;

import javax.sql.DataSource;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.core.PreparedStatementSetter;
import org.springframework.jdbc.core.RowCallbackHandler;

import com.bcxy.spring.dao.model.TestModel;

public class SpringDao {

 DataSource ds = null;
 
 JdbcTemplate jt = null;
 
 Log log = LogFactory.getLog(SpringDao.class);
 
 public List springQuery(){
  final List tests = new ArrayList();
  String sql = " select * from test ";
  jt = new JdbcTemplate(ds);
  jt.query(sql, new RowCallbackHandler(){

   public void processRow(ResultSet rs) throws SQLException {
    //
    TestModel tm = new TestModel();
    tm.setId(rs.getInt("id"));
    tm.setPw(rs.getString("pw"));
    tm.setUn(rs.getString("un"));
    //
    tests.add(tm);
   }
  });
  return tests;
 }
 
 public void springUpdate() {
  String sql = "update test set pw=? where id=?";
  jt = new JdbcTemplate(ds);
  jt.update(sql, new PreparedStatementSetter() {
   public void setValues(PreparedStatement ps) throws SQLException {
    //
    ps.setString(1, "maxcard");
    ps.setInt(2, 1);
   }
  });
  log.info("update test a record.");
 }

 /**
  * @return
  */
 public DataSource getDs() {
  return ds;
 }

 /**
  * @param source
  */
 public void setDs(DataSource source) {
  ds = source;
 }

}

Spring配置文件

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
<description>Spring Quick Start</description>
<!-- datasource -->
<bean id="datasource"
      class="org.apache.commons.dbcp.BasicDataSource"
      destroy-method="close">
    <property name="driverClassName">
        <value>com.mysql.jdbc.Driver</value>
    </property>
    <property name="url">
        <value>jdbc:mysql://localhost/test</value>
    </property>
    <property name="username">
        <value>root</value>
    </property>
    <property name="password">
        <value></value>
    </property>
</bean>
<!-- test dao -->
<bean id="testdao"
      class="com.bcxy.spring.dao.SpringDao"
      >
    <property name="ds">
        <ref local="datasource"/>
    </property>
</bean>

</beans>

下面我们用JUnit测试一下:
......

 public void testSpringUpdate() throws FileNotFoundException {
     //
  InputStream is = new FileInputStream("bean.xml");
  XmlBeanFactory bean = new XmlBeanFactory(is);
  SpringDao sd = (SpringDao)bean.getBean("testdao");
  sd.springUpdate();
 }