我计划完成 50 到 100 篇有关 Spring 的文章，这是第十四篇。本文对应Spring in Action（Spring实战）第四版第五章的5.1.1（5.1.1 Following the life of a request），将讲述Spring MVC中请求的流程。
每当用户在浏览器点击链接或者提交表单的时候，就会生成一个request。request就像一个邮差，负责将信息从一个地方地方传递到另一个地方。
request很忙，它从离开浏览器开始，一直到跟着response返回到浏览器结束，会经过很多站，而每一站都释放一些信息，又带上一些新的信息。下图显示了在Spring MVC中，request在哪些站点停留。
- 第一步，当request从浏览器发出时，它携带了用户的请求信息，至少会携带请求的url地址，但也可能携带其它数据，比如用户在表单中提交的信息。
在Spring MVC中，DispatcherServlet实现了第一步的功能。和大多数基于Java的web框架一样，Spring MVC通过一个前端控制器servlet(front controller servlet)来处理请求。前端控制器是一种通用的web应用特征，使用一个单独的servlet，将请求转发给应用的其它组件，而后面的这些组件负责实际的处理。在Spring MVC中，DispatcherServlet就是这个前端控制器。 - 第二步，为请求找到匹配的控制器。DispatcherServlet的任务是将请求发送给Spring MVC控制器（controller）。控制器负责处理这些请求。但是一个web应用一般不会只有一个控制器，所以DispatcherServlet需要一些帮助来决定将请求发给哪个控制器。要做到这点，DispatcherServlet需要询问一个或多个handler mappings，因为handler mappings注重请求的url。
- 第三步，DispatcherServlet将请求发给选中的控制器，在控制器中，请求转交了用户在表单中提交的信息，并且耐心等待控制器处理这些信息。实际上，在设计得比较好的应用中，控制器自身一般很少处理业务逻辑，而是调用service来处理。
- 第四步，控制器或service处理业务逻辑之后，会产生一些信息，返回给用户，并且在浏览器中展示。这些信息被称为model。把这些信息直接返回给浏览器往往不够，它往往需要以用户友好的方式，比如html的方式返回。所以，需要视图，比如JSP来展示这些信息。控制器会将model打包好，并且决定要渲染model的视图名称，然后将请求，以及model和视图名称，返回给DispatcherServlet。
- 第五步，DispatcherServlet需要依靠视图解析器，根据视图名称，匹配具体的视图实现。需要注意的是，视图实现不一定是JSP,也可以是其它类型的模板。
- 第六步，视图将model中的数据进行渲染，生成需要返回给客户端的输出。
- 第七步，将结果返回给客户端。
以上就是Spring MVC中请求的处理流程，有哪里写得不够清楚的地方，欢迎在评论区进行讨论。