写在前面的话：
最近被项目的代码折腾的死去活来的，其实框架也没有那么难理解，只是自己的Web基础太差，被Request和Response这一对神雕侠侣坑到泪流满面！今天捣腾了一下Spring
Web
MVC，本来想用JSTL的自定义标签开发或者Strust2的框架，但发现框架堆的太多太乱不利于开发效率，所以决定还是先采用Spring
Web
MVC的设计模式来试一试。然后，在网上搜了很多资料之后，我发现，大家基本上都是转发+贴代码，可以学习的东西实在是少之又少，在调试了一天别人的代码
之后，我决定直接去看Spring-Framework的官方文档：spring-framework-reference。由于这份文档目前还没有找到
中文版的，所以我把一些重要的内容按章节翻译下来，一方面留给自己当作参考资料，另一方面也是希望能帮助到想要学习Spring
framework的人。
PS：英语水平不是很高，部分内容翻译不流畅，希望见谅，如有错误，麻烦留言指正，不胜感激。
和许多其他Web MVC框架一样，Spring Web MVC是由request驱动，以servlet为中心设计的，而这个中心servlet能够将request分发到不同的控制器 (controllers)，然后提供其他的能够用来开发Webapplication的功能模块。然而，Spring的DispatcherServlet能够做的更多，它能够完全和Spring IoC容器结合，并且能够允许开发人员使用Spring容器中所有的要素；
Request处理Spring Web MVC工作流的时候，DispatcherServlet所发挥的作用在下面的图中一览无余：
一些精通模式的读者会马上意识到，DispatcherServlet就是“前端控制器”（这是一种Spring Web MVC与其他先进的Web框架所共有的模式）设计模式的一种表达。
DispatcherServlet 本质上就是一个Servlet（继承了HttpServlet基类），在你的Web应用中使用它的时候，要在Web.xml中声明。同样的，你需要在 Web.xml中利用URL映射的方式，将那些你想要交给DispatcherServlet处理的requests进行映射。下面是一个标准的J2EE Servlet配置：
在一些处理例子中，所有的以.form结束的requests将会被交给上述所声明DispatcherServlet处理。这仅仅是搭建Spring Web MVC的第一步。你现在需要配置那些在Spring Web MVC框架中所使用到的各种beans(也包括DispatcherServlet自己)。
在3.13部分，详细讲述了关于添加可用的ApplicationContext的内容，在Web MVC 框架中，每一个DispatcherServlet都有自己的WebApplication-Context，从已经被定义的根应用上下文中继承所有的 beans，这些被继承的beans能够在特定的Servlet范围内被覆盖，开发者也可以给一个给定的Servlet实例定义新的特定范围的 beans。
在初始化DispatcherServlet的基础上,Spring Web MVC框架开始在你的Web应用WEB-INF的路径下寻找一个叫做[servlet-name]-servlet.xml的文件，然后以重新定义那些已 经以相同的名称在全局范围内定义的任何一个beans的方式创建这些已经在这个xml中被定义的beans。
思考下面的DispatcherServlet声明配置：
在拥有上述的Servlet配置文件之后，你需要在你的应用里创建一个/WEB-INF/golfing-servlet.xml的文件，这个文件将会包 含你的所有Spring Web MVC组件（beans），你能够通过一个servlet初始化参数去更改这个beans的配置文件的绝对路径。
这个WebApplicationContext是从一个拥有一些Web application的额外必备要素的基本应用上下文ApplicationContext拓展来的。这个Web应用上下文和普通的 ApplicationContext在解决方案的可用性上有些不同。并且能够知道这个Web 应用上下文归属于哪一个Servle。这些WebApplicationContext封装在ServletContext中的，通过使用RequestContextUtils类中的静态方法，你就能够在你需要使用它的时候立马找到这个WebApplicationContext。
Spring中的DispatcherServlet用特殊的beans处理request，并且用合适的视图表现。这些beans是Spring框架中的一部分。你能够在WebApplicationContext中配置它们，就如同你配置其他的bean一样。然而，对于大多数beans来说，敏感的默认行为能够为你提供，因此并不需要你去配置它们。
关于这些beans的描述如下表：
（简单介绍一下：
Handler mappings:操作执行一系列的预处理、后续处理，当得到匹配的参数之后，就执行控制器；
View resolvers:将视图名称解析给视图；
Locale resolver:是一种为了提供国际化视图而对客户端使用的环境场所解析；
Theme resolver:能够解析你的Web 应用使用的主题，举个例子：提供个性化的布局；
Multipart file resolver:包括了能够处理HTML表单上的下载文档；
Handler exception resolvers:映射视图的异常或者实现其他更多更复杂的异常处理代码；
在你建立DispatcherServlet之后，一个请求进入了一个特定的DispatcherServlet，这个DispatcherServlet开始如下面的的过程一样处理这个请求：
1、 WebApplicationContext搜索并且将这个request封装成一个属性，这样控制器和这个过程中的其他元素就能够使用了。这样的封装默 认是由Key—DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE执行的。
2、Locale resolve通过封装请求是为了让解析场所所使用的元素变为可用。这是过程中的可选项。
3、（很简单自己看，翻累了）The theme resolver is bound to the request to let elements such as views determine which theme to use. If you do not use themes, you can ignore it.
4、寻找一个合适的Handler，如果这个Handler被找到了，和这个Handler所关联的处理链开始执行，并准备返回一个model或者View。
5、如果返回的是Model,视图就表现出来。如果返回的不是model（也许是因为预处理器或者后续处理拦截了这个请求，也许是因为安全原因），没有视图表现出来，因为request已经被完成了。