一、工作流程
话不多说直接上图：
1、用户发送请求被前端控制器DispatcherServler接收
2、DispatcherServler收到前端的请求后会调用处理器映射器HandlerMapping
3、处理器映射器找到具体的处理器（可以根据XML配置、注解等方式查找和匹配），然后生成处理器对象和处理器拦截器（如果有配置的话会生成），最终将生成的处理器对象返回给前端控制器DispatcherServler。
4、前端控制器DispatcherServler收到处理器对象之后，则调用处理器适配器HandlerAdapter
5、HandlerAdapter处理器适配器通过适配调用具体的处理器（ Controller ，也称后端控制器）。
６、 Controller 执行完并返回 ModelAndView 。
７、 HandlerAdapter将controller执行结果ModelAndView返回给前端控制器DispatcherServlet。
８、前端控制器DispatcherServler接受返回的ModelAndView 之后传给 ViewReslover 视图解析器。
９、 ViewReslover 视图解析器解析并返回具体的 View。
１０、 DispatcherServlet 前端控制器根据View进行渲染视图，将模型数据填充到视图中。
１１、DispatcherServlet 前端控制器响应用户。
二、为什么要使用SpringMVC
使用MVC即请求-响应的模型，目的是为了简化web开发和解决处理业务数据的对象和显示业务数据的视图之间耦合
三、什么是MVC设计模式
MVC即Model-View-Controller，将应用按照Model（模型）、View（视图）、Controller（控制）这样的方式分离。
视图(View)：代表用户交互界面，对于Web应用来说，可以是HTML，也可能是jsp、XML和Applet等。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。
模型(Model)：是业务的处理以及业务规则的制定。模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计是MVC最主要的核心。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只是组织管理这些模型，以便于模型的重构和提高重用性。
控制(Controller)：可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。
四、SpringMVC特点和优点列举
特点：
清晰的角色划分：控制器（controller）、验证器（validator）、 命令对象（command object）、表单对象（formobject）、模型对象（model object）、 Servlet分发器（DispatcherServlet）、处理器映射（handler mapping）、视图解析器（view resolver）等。每一个角色都可以由一个专门的对象来实现。
可适配、非侵入：可以根据不同的应用场景，选择合适的控制器子类 （simple型、command型、form型、wizard型、multi-action型或者自定义），而不是从单一控制器 （比如Action/ActionForm）继承。
可重用的业务代码：可以使用现有的业务对象作为命令或表单对象，而不需要去扩展某个特定框架的基类。
可定制的handlermapping和view resolution：Spring提供从最简单的URL映射， 到复杂的、专用的定制策略。与某些webMVC框架强制开发人员使用单一特定技术相比，Spring显得更加灵活。
可定制的本地化和主题（theme）解析：支持在JSP中可选择地使用Spring标签库、支持JSTL、支持Velocity（不需要额外的中间层）等等。
优点：
- 天生与Spring框架集成（如IoC容器、AOP等）
- 非常灵活的数据验证、格式化和数据绑定机制
- 支持Restful风格等等
五、SpringMVC常用注解
@Controller：标识这个类是一个控制器
@RequestMapping：给控制器方法绑定一个uri
@ResponseBody：将java对象转成json，并且发送给客户端
@RequestBody：将客户端请求过来的json转成java对象
@RequestParam：当表单参数和方法形参名字不一致时，做一个名字映射
@PathVarible：用于获取uri中的参数,比如user/1中1的值
Rest风格的新api
@RestController相当于@Controller+ @ResponseBody
@GetMapping@DeleteMapping@PostMapping@PutMapping
其他注解
@SessionAttribute：声明将什么模型数据存入session
@CookieValue：获取cookie值
@ModelAttribute：将方法返回值存入model中
@HeaderValue：获取请求头中的值
六、SpringMVC和Struts2的对比
框架机制：SpringMVC的入口是servlet，而Struts2是filter。
Filter在容器启动后就初始化，服务停止后销毁，晚于Servlet；Servlet在是在调用时初始化，先于Filter调用，服务停止后销毁。
拦截机制：
Struts2：1、Struts2框架是类级别的拦截，每次请求就会创建一个Action，和Spring整合时Struts2的ActionBean注入作用域是原型模式prototype（否则会出现线程并发问题），然后通过setter，getter吧request数据注入到属性；
2、一个Action对应一个request，response上下文，在接收参数时，可以通过属性接收，说明属性参数是让多个方法共享的；
3、Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。
SpringMVC:1、SpringMVC是方法级别的拦截，一个方法对应一个Request上下文，所以方法直接基本上是独立的，独享request，response数据。而每个方法同时又何一个url对应，参数的传递是直接注入到方法中的，是方法所独有的。处理结果通过ModeMap返回给框架；
2、在Spring整合时，SpringMVC的Controller Bean默认单例模式Singleton，所以默认对所有的请求，只会创建一个Controller，有应为没有共享的属性，所以是线程安全的，如果要改变默认的作用域，需要添加@Scope注解修改；
Struts2有自己的拦截Interceptor机制，SpringMVC这是用的是独立的Aop方式，这样导致Struts2的配置文件量还是比SpringMVC大。
性能方面：SpringMVC实现了零配置，由于SpringMVC基于方法的拦截，有加载一次单例模式bean注入。而Struts2是类级别的拦截，每次请求对应实例一个新的Action，需要加载所有的属性值注入，所以，SpringMVC开发效率和性能高于Struts2。
配置方面：spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高（当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果，但是需要xml配置的地方不少）；
SpringMVC可以认为已经100%零配置。
设计思想：Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。
集成方面：SpringMVC集成了Ajax。
注意：springmvc是单例模式的框架,但它是线程安全的,因为springmvc没有成员变量,所有参数的封装都是基于方法的,属于当前线程的私有变量. 因此是线程安全的框架。所以效率高。struts action是多例的。所以可以使用成员变量获取参数。所以效率低。
七、MVC模式的不足
MVC模式早在上个世纪70年代就诞生了，直到今天它依然存在，可见生命力相当之强。MVC模式最早应用于Smalltalk语言中，最后在其它许多开发语言中都得到了很好的应用。随着包括Struts、Spring MVC在内的MVC框架的出现，MVC模式真正落地，并使得开发更加高效、代码耦合度尽量减小、应用程序各部分的职责更加清晰。
MVC的交互过程如下图所示
既然MVC模式这么好，难道它就没有不足的地方吗？我认为MVC至少有以下三点不足：
-
每次请求必须经过“控制器->模型->视图”这个流程，用户才能看到最终的展现的界面，这个过程似乎有些复杂；
-
实际上视图是依赖于模型的，换句话说，如果没有模型，视图也无法呈现出最终的效果；
-
渲染视图的过程是在服务端来完成的，最终呈现给浏览器的是带有模型的视图页面，性能无法得到很好的优化。
为了使数据展现过程更加直接，并且提供更好的用户体验，我们有必要对MVC模式进行改进。不妨这样来尝试：首先从浏览器发送AJAX请求，然后服务端接受该请求并返回JSON数据返回给浏览器，最后在浏览器中进行界面渲染。改进后的MVC模式如下图所示：
也就是说，我们输入的是AJAX请求，输出的是JSON数据，市面上有这样的技术来实现这个功能吗？答案是REST。
REST全称是Representational State Transfer（表述性状态转移），它是Roy Fielding博士在2000年写的一篇关于软件架构风格的论文，此文一出，威震四方！国内外许多知名互联网公司纷纷开始采用这种轻量级的Web服务，大家习惯将其称为RESTful Web Services，或简称REST服务。]
如果将浏览器这一端视为前端，而服务器那一端视为后端的话，可以将以上改进后的MVC模式简化为以下前后端分离模式，如下图所示：
可见，采用REST分格的架构可以使得前端关注界面展现，后端关注业务逻辑，分工明确，职责清晰。
那么，如何使用REST架构将应用程序进行前后端分离呢？ 我们歇会，有空再讲！
来源：oschina
链接：https://my.oschina.net/TomcatJack/blog/3222933