（2）修改WEB-INF目录的web.xml

 定义DispatcherServlet来控制所有的请求，同时具有一个标准的servlet-mapping映射到*.htm URL模式

   < servlet >
     < servlet - name > springapp </ servlet - name >
     < servlet - class > org.springframework.web.servlet.DispatcherServlet </ servlet - class >
     < load - on - startup > 1 </ load - on - startup >
   </ servlet >
 
   < servlet - mapping >
     < servlet - name > springapp </ servlet - name >
     < url - pattern > * .htm </ url - pattern >
   </ servlet - mapping >

创建springapp-servlet.xml（应用程序名--servlet.xml），配置DispatcherServlet要使用的Web应用程序context

定义名为springappController的Bean条目，指向SpringappController控制器

使用SimpleUrlHandlerMapping来定义URL映射，将/hello.htm映射到SpringappController控制器

<? xml version = " 1.0 "  encoding = " UTF-8 " ?>
<! DOCTYPE beans PUBLIC  " -//SPRING//DTD BEAN//EN "   " http://www.springframework.org/dtd/spring-beans.dtd " >
 
<!--
   -  Application context definition  for   " springapp "  DispatcherServlet.
   -->
 
< beans >
     < bean id = " springappController "   class = " SpringappController " />
 
     < bean id = " urlMapping "   class = " org.springframework.web.servlet.handler.SimpleUrlHandlerMapping " >
         < property name = " mappings " >
             < props >
                 < prop key = " /hello.htm " > springappController </ prop >
             </ props >
         </ property >
     </ bean >
</ beans >

（8）拷贝jars到WEB-INF/lib目录

将dist/spring.jar、lib/jakarta-commons/commons-logging.jar、lib/log4j/log4j-1.2.8.jar文件导入到springapp工程的springapp/WEB-INF/lib目录下

（9）创建控制器

实现Controller接口的handleRequest()方法来处理请求

这里添加日志记录，检查是否执行到这里

handleRequest()方法返回的ModelAndView没有指定Model，所以直接重定向到指定的视图hello.jsp

import  org.springframework.web.servlet.mvc.Controller;
import  org.springframework.web.servlet.ModelAndView;
 
import  javax.servlet.ServletException;
import  javax.servlet.http.HttpServletRequest;
import  javax.servlet.http.HttpServletResponse;
 
import  java.io.IOException;
 
import  org.apache.commons.logging.Log;
import  org.apache.commons.logging.LogFactory;
 
public   class  SpringappController  implements  Controller  {
 
     /** */ /**  Logger for this class and subclasses  */
     protected   final  Log logger  =  LogFactory.getLog(getClass());
 
     public  ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response)
             throws  ServletException, IOException  {
 
        logger.info( " SpringappController - returning hello view " );
 
         return   new  ModelAndView( " hello.jsp " );
    }
}

（10）创建视图hello.jsp

< html >
     < head >< title > Example :: Spring Application </ title ></ head >

     < body >
         < h1 > Hello  -  Spring Application </ h1 >
         < p > Greetings. </ p >
     </ body >
</ html >

1 ：核心容器：核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用控制反转 （IOC） 模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。

2 ：Spring 上下文：Spring 上下文是一个配置文件，向 Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。

3 ：Spring AOP：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了Spring 框架中。所以可以很容易地使 Spring 框架管理的任何对象支持AOP。Spring AOP 模块为基于Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP，不用依赖 EJB 组件，就可以将声明性事务管理集成到应用程序中。

4：Spring DAO：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。
 
5 ：Spring ORM：Spring 框架插入了若干个 ORM 框架，从而提供了 ORM 的对象关系工具，其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。
 
6 ：Spring Web 模块：Web 上下文模块建立在应用程序上下文模块之上，为基于 Web 的应用程序提供了上下文。所以，Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。

7 ：Spring MVC 框架：MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口，MVC 框架变成为高度可配置的，MVC 容纳了大量视图技术，其中包括 JSP、Velocity、Tiles、iText（PDF） 和 POI（Excel）。

Spring 框架的功能可以用在任何 J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问，这样的对象可以在不同 J2EE 环境 （Web 或 EJB）、独立应用程序、测试环境之间重用。

IOC 和 AOP

控制反转模式（也称作依赖性介入）的基本概念是：不创建对象，但是描述创建它们的方式。在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。容器 （在 Spring 框架中是 IOC 容器） 负责将这些联系在一起。

在典型的 IOC 场景中，容器创建了所有对象，并设置必要的属性将它们连接在一起，决定什么时间调用方法。下表列出了 IOC 的一个实现模式。

类型 1 服务需要实现专门的接口，通过接口，由对象提供这些服务，可以从对象查询依赖性（例如，需要的附加服务）
类型 2 通过 JavaBean 的属性（例如 setter 方法）分配依赖性
类型 3 依赖性以构造函数的形式提供，不以 JavaBean 属性的形式公开

Spring 框架的 IOC 容器采用类型 2 和类型3 实现。

面向方面的编程

面向方面的编程，即 AOP，是一种编程技术，它允许程序员对横切关注点或横切典型的职责分界线的行为（例如日志和事务管理）进行模块化。AOP 的核心构造是方面，它将那些影响多个类的行为封装到可重用的模块中。

AOP 和 IOC 是补充性的技术，它们都运用模块化方式解决企业应用程序开发中的复杂问题。在典型的面向对象开发方式中，可能要将日志记录语句放在所有方法和 Java 类中才能实现日志功能。在 AOP 方式中，可以反过来将日志服务模块化，并以声明的方式将它们应用到需要日志的组件上。当然，优势就是 Java 类不需要知道日志服务的存在，也不需要考虑相关的代码。所以，用 Spring AOP 编写的应用程序代码是松散耦合的。

AOP 的功能完全集成到了 Spring 事务管理、日志和其他各种特性的上下文中。

IOC 容器

Spring 设计的核心是 org.springframework.beans 包，它的设计目标是与 JavaBean 组件一起使用。这个包通常不是由用户直接使用，而是由服务器将其用作其他多数功能的底层中介。下一个最高级抽象是 BeanFactory 接口，它是工厂设计模式的实现，允许通过名称创建和检索对象。BeanFactory 也可以管理对象之间的关系。

BeanFactory 支持两个对象模型。

单态 模型提供了具有特定名称的对象的共享实例，可以在查询时对其进行检索。Singleton 是默认的也是最常用的对象模型。对于无状态服务对象很理想。
 
原型 模型确保每次检索都会创建单独的对象。在每个用户都需要自己的对象时，原型模型最适合。

bean 工厂的概念是 Spring 作为 IOC 容器的基础。IOC 将处理事情的责任从应用程序代码转移到框架。正如我将在下一个示例中演示的那样，Spring 框架使用 JavaBean 属性和配置数据来指出必须设置的依赖关系。

BeanFactory 接口

因为 org.springframework.beans.factory.BeanFactory 是一个简单接口，所以可以针对各种底层存储方法实现。最常用的 BeanFactory 定义是 XmlBeanFactory，它根据 XML 文件中的定义装入 bean，如清单 1 所示。

BeanFactory factory  =   new  XMLBeanFactory( new  FileInputSteam( " mybean.xml " ));

在 XML 文件中定义的 Bean 是被消极加载的，这意味在需要 bean 之前，bean 本身不会被初始化。要从 BeanFactory 检索 bean，只需调用 getBean() 方法，传入将要检索的 bean 的名称即可，如清单 2 所示。

MyBean mybean  =  (MyBean) factory.getBean( " mybean " );

 每个 bean 的定义都可以是 POJO （用类名和 JavaBean 初始化属性定义） 或 FactoryBean。FactoryBean 接口为使用 Spring 框架构建的应用程序添加了一个间接的级别。

IOC 示例

理解控制反转最简单的方式就是看它的实际应用。在对由三部分组成的 Spring 系列 的第 1 部分进行总结时，我使用了一个示例，演示了如何通过 Spring IOC 容器注入应用程序的依赖关系（而不是将它们构建进来）。

我用开启在线信用帐户的用例作为起点。对于该实现，开启信用帐户要求用户与以下服务进行交互：

信用级别评定服务，查询用户的信用历史信息。
远程信息链接服务，插入客户信息，将客户信息与信用卡和银行信息连接起来，以进行自动借记（如果需要的话）。
电子邮件服务，向用户发送有关信用卡状态的电子邮件。

三个接口

对于这个示例，我假设服务已经存在，理想的情况是用松散耦合的方式把它们集成在一起。以下清单显示了三个服务的应用程序接口。

public   interface  CreditRatingInterface  {
       public   boolean  getUserCreditHistoryInformation(ICustomer iCustomer);
}

清单 3 所示的信用级别评定接口提供了信用历史信息。它需要一个包含客户信息的 Customer 对象。该接口的实现是由 CreditRating 类提供的。

public   interface  CreditLinkingInterface  {
     public  String getUrl();
     public   void  setUrl(String url);
     public   void  linkCreditBankAccount()  throws  Exception ;
}

信用链接接口将信用历史信息与银行信息（如果需要的话）连接在一起，并插入用户的信用卡信息。信用链接接口是一个远程服务，它的查询是通过 getUrl() 方法进行的。URL 由 Spring 框架的 bean 配置机制设置，我稍后会讨论它。该接口的实现是由 CreditLinking 类提供的。

public   interface  EmailInterface  {
       public   void  sendEmail(ICustomer iCustomer);
       public  String getFromEmail();
       public   void  setFromEmail(String fromEmail) ;
       public  String getPassword();
       public   void  setPassword(String password) ;
       public  String getSmtpHost() ;
       public   void  setSmtpHost(String smtpHost);
       public  String getUserId() ;
       public   void  setUserId(String userId);
   }

EmailInterface 负责向客户发送关于客户信用卡状态的电子邮件。邮件配置参数（例如 SMPT 主机、用户名、口令）由前面提到的 bean 配置机制设置。Email 类提供了该接口的实现。

Spring 使其保持松散

这些接口就位之后，接下来要考虑的就是如何用松散耦合方式将它们集成在一起。在 清单 6 中可以看到信用卡帐户用例的实现。

注意，所有的 setter 方法都是由 Spring 的配置 bean 实现的。所有的依赖关系 （也就是三个接口）都可以由 Spring 框架用这些 bean 注入。createCreditCardAccount() 方法会用服务去执行其余实现。

<? xml version = " 1.0 "  encoding = " UTF-8 " ?>
<! DOCTYPE beans PUBLIC  " -//SPRING//DTD BEAN//EN "  
          " http://www.springframework.org/dtd/spring-beans.dtd " >
< beans >
     < bean id = " createCreditCard "   --> define createCreditCard definition
         class = " springexample.creditcardaccount.CreateCreditCardAccount " >
        
         < property name = " creditRatingInterface " >--> inject creditRatingInterface dependency  via creditRating reference bean
             < ref bean = " creditRating "   />
         </ property >
        
         < property name = " creditLinkingInterface " > " >-->inject creditLinkingInterface dependency  via creditLinking reference bean
             < ref bean = " creditLinking "   />
         </ property >
        
         < property name = " emailInterface " > " > " >--> inject emailInterface dependency  via email reference bean
             < ref bean = " email "   />
         / property >
     </ bean >

     < bean id = " creditLinking "   class = " springexample.creditlinking.CreditLinking " >
         < property name = " url " >
             < value > http: // localhost/creditLinkService</value>-->set url property value 
         </ property >
     </ bean >

     < bean id = " creditRating "   class = " springexample.creditrating.CreditRating " >
     </ bean >

     < bean id = " email "   class = " springexample.email.Email " >
         < property name = " smtpHost " >
             < value > localhost </ value >>--> set smpHtpHost property value 
         </ property >
        
         < property name = " fromEmail " >
             < value > mycompanyadmin@mycompanyadmin.com </ value >
         </ property >
        
         < property name = " userId " >
             < value > myuserid </ value >
         </ property >
        
         < property name = " password " >
             < value > mypassword </ value >
         </ property >
     </ bean >
</ beans >

运行应用程序

ClassPathXmlApplicationContext ctx  =  
         new  ClassPathXmlApplicationContext( new  String[]  {  " springexample-creditaccount.xml " } );

CreateCreditCardAccountInterface creditCardAccount  =  
                    (CreateCreditCardAccountInterface) ctx.getBean( " createCreditCard " );

Spring的MVC model类似于Struts。在多线程服务对象这点上，Spring的Controller类似于Struts Action，只有一个实例处理所有客户的请求。然而，我们相信Spring的MVC比起Struts有很多优点，例如：

Spring在controllers，JavaBean，models和views提供了一个非常清晰的划分。

Spring的MVC是非常灵活的。不像Struts，它强制你的Action和Form对象进入固化的层次之中（因而你迫使你使用Java的实体继承），Spring MVC完全是基于接口的。而且，通过插入你自己的接口几乎Spring MVC 框架的所有部分都是可配置的。当然我们也提供了方便的类作为实现选择。

Spring MVC是真正的view无关的。你不会被强制使用JSP，如果你不想那么做的话。你可以使用Velocity，XSLT或其他view技术。如果你想要使用自定义的view机制——例如，你自己的模板语言——你可以简单实现Spring的View接口并且把它集成进来。

和其他对象一样，Spring的Controllers是通过IoC配置的。着使得它们易于测试，并且完美地和其他由Spring管理的对象集成。

Web层变成了业务对象层之上的薄薄一层。这鼓励了好的习惯。Struts和其他专门的web框架让你去实现你自己的业务对象；Spring提供了你应用程序所有层的集成。

如在Struts 1.1中所见的，你可以有和你在Spring MVC 应用程序中所需要的一样多的dispatcher servlets。

下面的例子展示了一个简单的Spring Controller如何能够访问定义在应用程序context中的业务对象。这个controller在它的handleRequest()方法中执行了Google搜索：

public   class  GoogleSearchController   implements  Controller  { 
         private  IGoogleSearchPort google; 
         private  String googleKey; 
         public   void  setGoogle(IGoogleSearchPort google)  { 
                 this .google  =  google; 
        }  

         public   void  setGoogleKey(String googleKey)  { 
                 this .googleKey  =  googleKey; 
        }  

         public  ModelAndView handleRequest( 
                                HttpServletRequest request, HttpServletResponse response) 
                 throws  ServletException, IOException  { 
                String query  =  request.getParameter( " query " ); 
                GoogleSearchResult result  =  
                         //  Google property definitions omitted 

                         //  Use google business object 
                        google.doGoogleSearch( this .googleKey, query, 
                                start, maxResults, filter, restrict, 
                                safeSearch, lr, ie, oe); 

                 return   new  ModelAndView( " googleResults " ,  " result " , result); 
        }  
}  

这段代码使用的prototype中，IGoogleSearchPort是一个GLUE web services代理，由Spring FActoryBean返回。然而，Spring把controller从底层web service库中分离出来。接口可以使用普通的Java对象，test stub，mock对象或者如下面要讨论的EJB代理实现。这个contorller不包括资源查找；除了支持它的web交互的必要代码之外没有别的什么了。

Spring还提供了数据绑定，forms，wizards和更复杂的工作流的支持。

      而Spring MVC则完全保留着Servlet概念中的request，response和session，并没有强制建立一个自己的概念模型（当然，他也有很烂的SimpleFormController，但你完全可以把它踢在一旁不管），也不强制需要FormBean和一堆XML定义。

      同时，它透明完成了与Spring的集成，Multi-action的派发，提供了绑定request数据用的binder等基本API。

      所以，如果想简单，使用Spring MVC的原始形态是一个很好的，类似于RoR中ActionPack的方案。

      推荐使用一个Controller响应一组相关动作的MultiActionController。同时，虽然一点不喜欢FormController定义的概念模型，但还是不影响发挥拿来主义，在共性比较明显后台管理模块，定义MultiActionFormController，自动完成某些共同的Form流程。


2.写给在用其他MVC框架程序员的快速入门

      也许，所有程序员都先放下自己框架里的概念模型，还原回一个JSP/Servlet程序员的角度，思考一个JSP/Servlet框架需要的功能。

     0. 配置文件

         Spring的配置文件默认为WEB-INF/xxxx-servelet.xml。

         其中xxx为web.xml中org.springframework.web.servlet.DispatcherServlet的servlet-name。

     1. 与Spring集成及IOC

          天然兮，由DispatcherServlet完成。

      2. Action及Multi-Action 分发
          Spring将按照配置文件定义的URL，Mapping到具体Controller类，再根据URL里的action= xxx或其他参数，利用反射调用Controller里对应的Action方法。

      3. 输入数据绑定 
          Spring提供Binder 通过名字的一一对应反射绑定Pojo，也可以直接从request.getParameter()取数据。
          如果没有另外加入框架封装，需要手工调用Binder.

      4. 输入数据验证 
          Sping 提供了Validator接口，而Spring Module还整合了Commons-Validaor 。

      5. 结果数据放回View 
          有个ModelAndView的概念，代表了返回的View名及数据(Model，一个Map)。可以用modelAndView.addObject()放入数据。当然，也可以直接request.setAttribute()。

      6. Interceptor 
          AOP概念，其实Servlet里面早有Filter概念，不过Inteceptor可以更灵活的Mapping，另提供postHandle的插入点
          preHandle() handler开工之前。
          postHandle() hander开工之后，但DispatchServlet还没有渲染页面。
          afterCompletion() 一切完工之后。
       

      7. Redirect，Forward页面及Token防止重复提交。

          Spring提供 "redirect:index.jsp", "forward:index.jsp"这样的简写。

          Spring Simple Form提供了防止重复提交的机制。

      8. 如果想直接编写Response返回字符串, 而不是返回一个View

          将函数的返回类型设为void，使用ss封装的 rendText(response,String text)函数。

3.Spring MVC Multi-action

3.1 基本配置

< bean id = " methodNameResolver "   class = " org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver " >         
     < property name = " paramName " >             
         < value > method </ value >         
     </ property >      
  
     < property name = " defaultMethodName " >             
         < value > index </ value >       
     </ property >  
</ bean >

以上配置将按xxx.do?method= list 将调用controller的list()方法

不过还要争取早日改为Web2.0式的写法./book/list.htm 要优于/book.do?action= list。

其余配置和其他Spring MVC配置差不多，请看bookstore-servlet.xml，留意下面几个关键节点

< bean id = " exceptionResolver " >
< bean id = " methodNameResolver " >
< bean id = " viewResolver " >
< bean id = " urlMapping " > (留意最新的urlMapping简写语法.) 

4.SpringSide BaseController
   继承于Spring的MultiActionController, 对其作了少量扩展--主要是对数据绑定的扩展，还加了一个SaveMessage函数。

   1.对数据绑定的扩展：

   a.InitBinder() 初始化Binder，注册日期类并允许数字类为空。

   b.对Bind and Validate函数的再包装
   本来Spring已有bind函数完成bind and validate, 但这个函数一来没有使用BindException作返回值而是抛出一个ServletException只好自己另外实现一个bindObject()函数。

   c.另外稍稍扩展了一些函数使其更好用。

2.SaveMessage():

如果是redirect的关系，message信息放在request.attribute()就会丢失，SaveMessage()将其放在session。
 配合messageFilter，在渲染页面前，把它从session又移回request。

5.后台管理通用的BaseManageController
  Spring MVC中的SimpleFormController中的交互机制有值得参考的部分，但其只有一个onSubmit函数不能很好的表达CRUD的语义，所以将两者结合成Multi-ActionFormController是比较好的方法。通过约定命名，在基类实现list()，create()等函数和默认流程，而在子类实现onList(),onCreate()函数。

   目前只是初步结合两者，还有很大的改进空间。

   参考了RoR中的命名。BaseManageController即按照此命名定义基类。

list 显示对象列表的页面 
create新增对象的输入界面
edit 修改对象的输入界面
show 只读显示对象detai的页面
save 新增对象的保存
update 修改对象的保存
remove 删除单个对象
removeAll 批量删除对象
query 查询

　　下面列举一下Spring的MVC framework在设计时做出的一些重要的决定，并将之和相关的MVC framework如Webwork2或struts进行对比:

　　一、Spring的整个MVC配置是基于IOC容器的

　　与struts或webwork2相比，这是一个ms有点奇怪的决定，看一下Spring MVC的配置文件，最先看到的不是action或者form，而是一些有着特定名字的bean，Bean下面的配置是一些简单或有点复杂的属性。我们看到的是机器更容易的数据结构，而不是人更容易理解的元素。

　　但是这恰恰是Spring的MVC强大的根源!因为它的配置就是Spring的核心IOC容器的配置，这意味着所有IOC容器的威力都可以在这里展现，我们可以为所欲为地对Spring MVC进行扩展和增强，我们可以完成在其它MVC framwork中很多难以想象的任务。想扩展新的URL映射方式吗?要换一个themeResolver或LocalReolver的实现吗?想在页面中显示新类型的View(比如说RDF，呵呵，一个小秘密:xiecc是研究语义网的，虽然成天不务正业，不写论文，只写八卦)?甚至想直接在Controller里定义AOP吗?这些对Spring的MVC来说都是小菜一碟。

　　我没有仔细研究过Webwork2的扩展机制，我知道通过Webwork2的interceptor机制，可以进行很多的扩展，甚至有一个简单的IOC容器。但不管它有多强大，提供了多少扩展点。它的威力都很难和真正的IOC容器相比。而struts的plugin功能则是出名的滥，虽然它也提供了plugin机制。

　　Spring采用IOC配置的另一个原因是使Spring的MVC与Spring的IOC容器的整合变得非常的容易。Spring提供了与struts与webwork2的整合，但是这样整合都需要在进行间接的包装，感觉总不是很自然。而且还会导致一个概念多个配置，webwork2就需要在Spring里配置bean，再配置自己的xwork文件。想象一下吧，我们的bean直接就是一个controller,直接可以完成MVC的所有任务,这是多少爽的感觉。

　　Rod Johnson采用IOC容器来实现的另一个原因是这会减少好多开发工作量。看一下urlMapping吧，它提供的property本身就是一个HashMap，只有配置完成，我们的bean里的数据就自然存在了，哈哈，好爽吧。不用象struts那样解析XML，再把它的内容一项一项地读到HashMap里。

　　虽然这样的配置会有点怪异，但假如我们对Spring的IOC容器非常熟悉的话，会发现它非常的亲切，也非常的简单。

　　最后是一个简单的小秘密，Spring怎么知道某个bean的配置就是urlMapping?另一个bean的配置就是viewResolver?其实很简单，把所有的bean全部读到内存里，然后通过bean的名字或类型去找就行了。通过名字去找就是简单的getBean方法，通过类型去找则使用了BeanFactoryUtils.beansOfTypeIncludingAncestors的静态方法。

　　二、Spring提供了明确的Model, View概念和相应的数据结构

　　在Spring里有一个有趣的数据类型叫做ModelAndView，它只是简单地把要显示的数据和显示的结果封装在一个类里。但是它却提供了明确的MVC概念，尤其是model概念的强化，使程序的逻辑变得更清晰了。

　　记得以前在Struts里写程序里的时候，为了显示数据经常自己把东西放到HttpSession或HttpServletRequest里(或set到form里，虽然不太有用)，这造成了model概念的模糊，而且也导致了struts与JSP页面的紧耦合。假如我们要替换成Veloctiy,就得另外加一个plugin,因为在velocity里数据是不需要不放到request里的。

　　Webwork2里强调的是与Web framework解耦和它的command模式的简单性，因此在它的action里只有简单的get或set方法，假如返回数据，也只是简单地返回一个String。当然这样的实现有它的好处，但是它淡化了model和view的概念。Rod Johnson认为Webwork2里的Action同时包含了Action和Model的职责，这样一个类的职责太多，不是一个很好的设计。当然Jason Carreira不太认同这种观点，因为Action里的model对象完成可以delege给其它对象。但不管怎样，这种争论的根源在于Webwork2里淡化了model, view甚至web的概念。仁者见仁，智者见智，最后的结果还是看个人喜欢好吧。

　　三、Spring的Controller是Singleton的，或者是线程不安全的

　　和Struts一样，Spring的Controller是Singleton的，这意味着每个request过来，系统都会用原有的instance去处理，这样导致了两个结果:我们不用每次创建Controller，减少了对象创建和垃圾收集的时间;由于只有一个Controller的instance，当多个线程调用它的时候，它里面的instance变量不是线程安全的。

　　这也是Webwork2吹嘘的地方，它的每个Action都是线程安全的。因为每过来一个request，它就创建一个Action对象。由于现代JDK垃圾收集功能的效率已经不成问题，所以这种创建完一个对象就扔掉的模式也得到了好多人的认可。Rod Johnson甚至以此为例证明J2EE提供的object pool功能是没多大价值的。

　　但是当人们在吹嘘线程安全怎么怎么重要的时候，我想请问有多少人在多少情况下需要考虑线程安全?Rod Johnson在分析EJB的时候也提出过其它问题，并不是没有了EJB的线程安全魔法，世界就会灭亡的，大多数情况下，我们根本不需要考虑线程安全的问题，也不考虑object pool。因为我们大多数情况下不需要保持instance状态。

　　至少我写了那么多的struts Action，写了那么多的Spring Controller，几乎没有碰到需要在instance变量保持状态的问题。当然也许是我写的代码不够多，Struts的设计者Craig R. McClanahan曾经说当时他设计struts时有两个条件不成熟:当时没有测试驱动开发的概念;当时JVM的垃圾收集性能太次。假如现在重新设计的话，他也会采用每个request生成一个新对象的设计方法，这样可以解决掉线程安全的问题了。

　　四、Spring不象Webwork2或tapestry那样去隐藏Servlet相关的元素如HttpServletRequest或HttpServletResponse

　　这又是一个重要的设计决定。在Webwork2里我们没有HttpServletRequest或者HttpServletResponse，只有getter, setter或ActionContext里数据，这样的结果导致一个干净的Action，一个与Web完全无关的Action，一个可以在任何环境下独立运行的bean。那么Webwork2的这样一个基于Command模式的Action究竟给我们带来了什么?我想主要有两点:

　　1、它使我们的Action可以非常容易地被测试。

　　2、用户可以在Action里添加业务逻辑，并被其它类重用。

　　然而仔细跟Spring比较一下，我们就会发现这两点功能所带来的好处其实并不象我们想象的那么显著。Spring的Controller类也可以非常轻松被测试，看一下spring-mock下面的包吧，它提供的MockHttpServletRequest, MockHttpServletResponse还有其它一些类让测试Controller变得异常轻松。再看一下Action里的业务逻辑吧，Jason Carreira曾经说我们可以尽情地在Webwork2的Action里加业务逻辑，因为Action是不依赖于Web的。但是有多少人真正往Action里加业务逻辑的?大多数人都会业务逻辑delegate（委派)给另一个Service类或Manager类。因为我们很清楚，往Action里加业务逻辑会使整个体系的分层架构变得不清晰，不管怎样，Web层就是Web层，业务层就是业务层，两者的逻辑混在一起总会带来问题的。而且往Action里加业务逻辑会使用这个Action类变得庞大，Webwork2的Action是每个request都创建实例的，尽管带来的性能影响不太大，但并不表示每次都要把业务逻辑再new出来，业务逻辑在大多数的情况下应该是单例的。

　　不把request和response展现给用户当然还会带来功能上的损失，也许一般的场合，用用webwork2提供的接口已经足够了，但有时我们必须要知道request和response才能发挥出更大的威力。比如我以前的一个项目里有一个通过递归动态生成的树状结构的页面，在jsp页面上显示递归是痛苦或不可能的，因此我用response直接write出页面，这在spring里很easy，但在webwork里可能比较难了(偶不敢肯定，偶研究得不够深，也许高手是有办法的)。

　　五、Spring提供了不错但不够充分的interceptor(拦截机)机制

　　回头看一下struts，它在架构里甚至没有给我们提供hook point的机会，我们没有任何机会加入自己的interceptor。我们只能通过重载struts的RequestProcessor类来进行一点有限的扩展。

　　到了Webwork2，似乎interceptor一下子成了整个Framework的核心，除了Action的核心部件，其它所有的东西都是interceptor。它的超强的interceptor功能使们扩展整个架构变得非常方便。有人称这种interceptor为AOP，Jason Carreira则自豪地宣称这个叫做pragamtic AOP。我不认同这是AOP，它只是简单的interceptor机制。但不管如何，它的interceptor确实有强大的功能。

　　Spring也提供了它的interceptor机制，它的HandlerInterceptor三个interceptor方法:peHandle, postHandle, afterCompletion。分别对应Controller执行前，Controller执行后和page render之后。虽然大多数情况下已经够用，但是从功能上来说显然它没有Webwork2强大。从AOP的角度来看，它没有提供around interceptor，而只有before与after interceptor。这意味着我们无法在interceptor前后保持状态，最简单的情况假如我们要计算一个Controller的执行时间，我们必须在执行完before后把begintime这个状态保持住，再在after里把它调出来，但是显然这个状态保持会是个问题，我们不能把它放到instance变量里，因为interceptor不是线程安全的。也许通过ThreadLocal可以解决这个问题，但是如此简单的功能要用到这样的方法来处理，显然这个Interceptor本身设计上还是有点问题的。

　　六、Spring提供了MultiActionController，使它可以在一个类里包含多个Action

　　这个设计和struts的DispatchAction有点类似，只不过提供了更灵活的机制。当我们的项目变大的时候，把功能类似的方法放到同一个Action里完全值得的! Webwork2缺少这样的机制。假如看一下Spring的源代码，会发现其实实现MultiActionController的工作量相当的少，只不过是用反射机制把解析出来的方法名执行一下就完事了。其实Webwork2也完全可以提供这样的机制。虽然从设计上来说确实不是很优雅，但是它确实很有用。

　　七、Spring提供了更多的选择方式

　　看看Spring里提供的Controller吧，它提供了好多不同的Controller类。要生成Wizard吗?要专门用于提交form的Controller吗?要执多个方法的类吗?Spring提供了丰富的子类来扩展这些选择。当然我们还可以很轻松地自己扩展这些功能。

　　再看看Spring的ViewResolver吧， 它提供了无数不同类型的ViewResolver。更重要的是我们自定义我们的页面映射方式。看看strtus，看看webwork2，都会存在页面与forward name的一层间接转换，我们必须在配置文件里配置好某个字符串(典型的是success)对应的是那个页面。但是Spring里我们有了更大的自由度，我们可以采用webwork2的策略，也可以采用更简单的策略，如将JSP文件名去掉扩展名的映射方法。也许有人认为这种映射方式很幼稚，但是我觉得它是非常有用的方式，即使在大项目里。

　　还有新的扩展吗?看看Spring Web Flow吧，它是SpringFramework的子项目。它为一长串的基于页面流的Wizard页面提供了可配置的实现方式。在Spring 1.3里，它将是SpringFramework的一部分。

　　八、Spring的tag

　　尽管Spring的tag数量上少得可怜，但它却是精心设计的。它的目标很简单:让美工可以轻松地编辑页面。因为在Spring的页面里Text仍然是Text，checkbox仍然是CheckBox，而不象在struts或webwork2中的Tag。它只是用Springbind对输入内容进行了一下包装。所以尽管页面显示代码上会比Webwork2多，但这绝对是有价值的。

　　在接下来的几章里，我会分析一下Spring是如何让我们的Web应用不需要知道ApplicationContext就能够访问IOC容器的，然后会对Spring的设计和执行过程进行简单的源码分析，然后给出几个扩展Spring MVC的方法。

DispatcherServlet

        DispathcerServlet的角色就好像是一个任意门，他位于spring mvc的"入口"想到那跟他说就对了。但是要使用任意门，您必需先安上他。要怎么按上呢? DispatcherServlet本身其实是一个Servlet，所以我们要做的事就是在web.xml中布署他。就如同一般Servlet布署的方式一样，描述servlet的名字和类别，再给他一个mapping描述适用的网页。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN''http://java.sun.com/dtd/web-app_2_3.dtd'>
 
<web-app>
 <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
 </servlet>
 
 <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>*.htm</url-pattern>
 </servlet-mapping>
</web-app>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN""http://www.springframework.org/dtd/spring-beans.dtd">
 
<!--
 - Application context definition for"dispatcher" DispatcherServlet.
 -->
 
<beans>
    <bean id="helloController" class="HelloController"/>

    <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="mappings">
            <props>
                <prop key="/hello.htm">helloController</prop>
            </props>
        </property>
    </bean>

    <bean id="viewResolver" class="org.springframework.web.servlet.view.UrlBasedViewResolver">
        <property name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property>
        <property name="prefix"><value>/WEB-INF/jsp/</value></property>
        <property name="suffix"><value>.jsp</value></property>
    </bean>

</beans>