（一）理论
一、Spring MVC原理
具体执行步骤如下：
1、 首先用户发送请求————>前端控制器，前端控制器根据请求信息（如URL）来决定选择哪一个页面控制器进行处理并把请求委托给它，即以前的控制器的控制逻辑部分；图中的1、2步骤；
2、 页面控制器接收到请求后，进行功能处理，首先需要收集和绑定请求参数到一个对象，这个对象在Spring Web MVC中叫命令对象，并进行验证，然后将命令对象委托给业务对象进行处理；处理完毕后返回一个ModelAndView（模型数据和逻辑视图名）；图中的3、4、5步骤；
3、 前端控制器收回控制权，然后根据返回的逻辑视图名，选择相应的视图进行渲染，并把模型数据传入以便视图渲染；图中的步骤6、7；
4、 前端控制器再次收回控制权，将响应返回给用户，图中的步骤8；至此整个结束。
问题：
1、 请求如何给前端控制器？
2、 前端控制器如何根据请求信息选择页面控制器进行功能处理？
3、 如何支持多种页面控制器呢？
4、 如何页面控制器如何使用业务对象？
5、 页面控制器如何返回模型数据？
6、 前端控制器如何根据页面控制器返回的逻辑视图名选择具体的视图进行渲染？
7、 不同的视图技术如何使用相应的模型数据？
首先我们知道有如上问题，那这些问题如何解决呢？请让我们先继续，在后边依次回答。
1、Spring Web MVC核心架构图：
架构图对应的DispatcherServlet核心代码如下：
Java代码
1、 //前端控制器分派方法
2、 protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
3、 HttpServletRequest processedRequest = request;
4、 HandlerExecutionChain mappedHandler = null;
5、 int interceptorIndex = -1;
6、
7、 try {
8、 ModelAndView mv;
9、 boolean errorView = false;
10、
11、 try {
12、 //检查是否是请求是否是multipart（如文件上传），如果是将通过MultipartResolver解析
13、 processedRequest = checkMultipart(request);
14、 //步骤2、请求到处理器（页面控制器）的映射，通过HandlerMapping进行映射
15、 mappedHandler = getHandler(processedRequest, false);
16、 if (mappedHandler == null || mappedHandler.getHandler() == null) {
17、 noHandlerFound(processedRequest, response);
18、 return;
19、 }
20、 //步骤3、处理器适配，即将我们的处理器包装成相应的适配器（从而支持多种类型的处理器）
21、 HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
22、
23、 // 304 Not Modified缓存支持
24、 //此处省略具体代码
25、
26、 // 执行处理器相关的拦截器的预处理（HandlerInterceptor.preHandle）
27、 //此处省略具体代码
28、
29、 // 步骤4、由适配器执行处理器（调用处理器相应功能处理方法）
30、 mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
31、
32、 // Do we need view name translation?
33、 if (mv != null && !mv.hasView()) {
34、 mv.setViewName(getDefaultViewName(request));
35、 }
36、
37、 // 执行处理器相关的拦截器的后处理（HandlerInterceptor.postHandle）
38、 //此处省略具体代码
39、 }
40、 catch (ModelAndViewDefiningException ex) {
41、 logger.debug(“ModelAndViewDefiningException encountered”, ex);
42、 mv = ex.getModelAndView();
43、 }
44、 catch (Exception ex) {
45、 Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
46、 mv = processHandlerException(processedRequest, response, handler, ex);
47、 errorView = (mv != null);
48、 }
49、
50、 //步骤5 步骤6、解析视图并进行视图的渲染
51、 //步骤5 由ViewResolver解析View（viewResolver.resolveViewName(viewName, locale)）
52、 //步骤6 视图在渲染时会把Model传入（view.render(mv.getModelInternal(), request, response);）
53、 if (mv != null && !mv.wasCleared()) {
54、 render(mv, processedRequest, response);
55、 if (errorView) {
56、 WebUtils.clearErrorRequestAttributes(request);
57、 }
58、 }
59、 else {
60、 if (logger.isDebugEnabled()) {
61、 logger.debug(“Null ModelAndView returned to DispatcherServlet with name ‘” + getServletName() +
62、 “‘: assuming HandlerAdapter completed request handling”);
63、 }
64、 }
65、
66、 // 执行处理器相关的拦截器的完成后处理（HandlerInterceptor.afterCompletion）
67、 //此处省略具体代码
68、
69、
70、 catch (Exception ex) {
71、 // Trigger after-completion for thrown exception.
72、 triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);
73、 throw ex;
74、 }
75、 catch (Error err) {
76、 ServletException ex = new NestedServletException(“Handler processing failed”, err);
77、 // Trigger after-completion for thrown exception.
78、 triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);
79、 throw ex;
80、 }
81、
82、 finally {
83、 // Clean up any resources used by a multipart request.
84、 if (processedRequest != request) {
85、 cleanupMultipart(processedRequest);
86、 }
87、 }
88、 }
核心架构的具体流程步骤如下：
1、 首先用户发送请求——>DispatcherServlet，前端控制器收到请求后自己不进行处理，而是委托给其他的解析器进行处理，作为统一访问点，进行全局的流程控制；
2、 DispatcherServlet——>HandlerMapping， HandlerMapping将会把请求映射为HandlerExecutionChain对象（包含一个Handler处理器（页面控制器）对象、多个HandlerInterceptor拦截器）对象，通过这种策略模式，很容易添加新的映射策略；
3、 DispatcherServlet——>HandlerAdapter，HandlerAdapter将会把处理器包装为适配器，从而支持多种类型的处理器，即适配器设计模式的应用，从而很容易支持很多类型的处理器；
4、 HandlerAdapter——>处理器功能处理方法的调用，HandlerAdapter将会根据适配的结果调用真正的处理器的功能处理方法，完成功能处理；并返回一个ModelAndView对象（包含模型数据、逻辑视图名）；
5、 ModelAndView的逻辑视图名——> ViewResolver， ViewResolver将把逻辑视图名解析为具体的View，通过这种策略模式，很容易更换其他视图技术；
6、 View——>渲染，View会根据传进来的Model模型数据进行渲染，此处的Model实际是一个Map数据结构，因此很容易支持其他视图技术；
7、返回控制权给DispatcherServlet，由DispatcherServlet返回响应给用户，到此一个流程结束。
到此，再来看我们前边提出的问题：
1、 请求如何给前端控制器？这个应该在web.xml中进行部署描述，在HelloWorld中详细讲解。
2、 前端控制器如何根据请求信息选择页面控制器进行功能处理？ 我们需要配置HandlerMapping进行映射
3、 如何支持多种页面控制器呢？配置HandlerAdapter从而支持多种类型的页面控制器
4、 如何页面控制器如何使用业务对象？可以预料到，肯定利用Spring IoC容器的依赖注入功能
5、 页面控制器如何返回模型数据？使用ModelAndView返回
6、 前端控制器如何根据页面控制器返回的逻辑视图名选择具体的视图进行渲染？ 使用ViewResolver进行解析
7、 不同的视图技术如何使用相应的模型数据？ 因为Model是一个Map数据结构，很容易支持其他视图技术
在此我们可以看出具体的核心开发步骤：
1、 DispatcherServlet在web.xml中的部署描述，从而拦截请求到Spring Web MVC
2、 HandlerMapping的配置，从而将请求映射到处理器
3、 HandlerAdapter的配置，从而支持多种类型的处理器
4、 ViewResolver的配置，从而将逻辑视图名解析为具体视图技术
5、处理器（页面控制器）的配置，从而进行功能处理
二、Spring Web MVC能帮我们做什么
√让我们能非常简单的设计出干净的Web层和薄薄的Web层；
√进行更简洁的Web层的开发；
√天生与Spring框架集成（如IoC容器、AOP等）；
√提供强大的约定大于配置的契约式编程支持；
√能简单的进行Web层的单元测试；
√支持灵活的URL到页面控制器的映射；
√非常容易与其他视图技术集成，如Velocity、FreeMarker等等，因为模型数据不放在特定的API里，而是放在一个Model里（Map数据结构实现，因此很容易被其他框架使用）；
√非常灵活的数据验证、格式化和数据绑定机制，能使用任何对象进行数据绑定，不必实现特定框架的API；
√提供一套强大的JSP标签库，简化JSP开发；
√支持灵活的本地化、主题等解析；
√更加简单的异常处理；
√对静态资源的支持；
√支持Restful风格。
三、Spring Web MVC优势
1、清晰的角色划分：前端控制器（DispatcherServlet）、请求到处理器映射（HandlerMapping）、处理器适配器（HandlerAdapter）、视图解析器（ViewResolver）、处理器或页面控制器（Controller）、验证器（ Validator）、命令对象（Command 请求参数绑定到的对象就叫命令对象）、表单对象（Form Object 提供给表单展示和提交到的对象就叫表单对象）。
2、分工明确，而且扩展点相当灵活，可以很容易扩展，虽然几乎不需要；
3、由于命令对象就是一个POJO，无需继承框架特定API，可以使用命令对象直接作为业务对象；
4、和Spring 其他框架无缝集成，是其它Web框架所不具备的；
5、可适配，通过HandlerAdapter可以支持任意的类作为处理器；
6、可定制性，HandlerMapping、ViewResolver等能够非常简单的定制；
7、功能强大的数据验证、格式化、绑定机制；
8、利用Spring提供的Mock对象能够非常简单的进行Web层单元测试；
9、本地化、主题的解析的支持，使我们更容易进行国际化和主题的切换。
10、强大的JSP标签库，使JSP编写更容易。
………………还有比如RESTful风格的支持、简单的文件上传、约定大于配置的契约式编程支持、基于注解的零配置支持等等。
四、structs和spring的MVC优势
1、spring3开发效率高于struts；
2、spring3 mvc可以认为已经100%零配置；
3、struts2是类级别的拦截， 一个类对应一个request上下文，springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应。所以说从架构本身上 spring3 mvc就容易实现restful url，而struts2的架构实现起来要费劲。因为struts2 action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了；
4、spring3mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架，方法之间不共享变量。而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的。这不会影响程序运行，却给编码读程序时带来麻烦 ；
5、由于Struts2需要针对每个Request进行封装，把Request，Session等Servlet生命周期的变量封装成一个一个Map，供给每个Action使用，并保证线程安全。所以在原则上，是比较耗费内存的。