跟踪 Spring MVC的请求

首先讲一个捕鼠器的游戏：
它的目标是发送一个小钢球，让它经过一系列稀奇古怪的装置，最后触发捕鼠器。小钢球穿过各种复杂的配件，从一个斜坡上滚下来，被跷跷板弹起，绕过一个微型摩天轮，然后被橡胶靴从桶中踢出去。经过这些后，小钢球会对那只可怜又无辜的橡胶老鼠进行捕获

MVC

• Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
• View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
• Controller（控制器）是应用程序中处理用户交互的部分。 通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。



而

Spring MVC 框架和捕鼠器有些类似。Spring 将请求在调度Servlet，处理器映射（handler mapping），控制器以及视图解析器（view resolver）之间移动，而捕鼠器中的钢球则会在各种斜坡，跷跷板以及摩天轮之间滚动。但是，不要将 Spring MVC 与 Rube Goldberg-esque捕鼠器游戏做过多比较。每一个 Spring MVC 中的组件都有特定的目的，并没有它那么复杂。



一路上请求会将信息带到很多站点，并生产期望的结果。

1. 在请求离开浏览器时1️⃣，会带有用户所请求内容的信息，至少会包含请求的 URL。但是还可能带有其他的信息，例如用户提交的表单信息。

2. 请求旅程的第一站是 Spring 的 DispatcherServlet。与大多数基于 Java 的 Web 框架一样，Spring MVC 所有的请求都会通过一个前端控制器（front controller）Servlet。前端控制器是常用的 Web 应用程序模式，在这里一个单实例的 Servlet 将请求委托给应用程序的其他组件来执行实际的处理。在 Spring MVC 中，DispatcherServlet 就是前端控制器。

3. DispatcherServlet的任务是将请求发送给 Spring MVC控制器（controller）。控制器是一个用于处理请求的 Spring 组件。在典型的应用程序中可能会有多个控制器，DispatcherServlet需要知道应该将请求发送给哪个控制器。所以DispatcherServlet会查询一个或多个处理器映射（handler mapping）2️⃣来确定请求的下一站在哪里。处理器映射会根据请求所携带的 URL 信息来进行决策。

4. 一旦选择了合适的控制器，DispatcherServlet会将请求发送给选中的控制器 3️⃣。到了控制器，请求会卸下其负载（用户提交的信息）并耐心等待控制器处理这些信息。实际上，设计良好的控制器本身只处理很少甚至不处理工作，而是将业务逻辑委托给一个或多个服务对象进行处理。

5. 控制器在完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户并在浏览器上显示。这些信息被称为模型（model）。不过仅仅给用户返回原始的信息是不够的，这些信息需要以用户友好的方式进行格式化，一般会是 HTML。所以，信息需要发送给一个视图（view），通常是 JSP。

6. 控制器所做的最后一件事，就是将模型数据打包，并且表示出用于渲染输出的视图名。它接下来会将请求连同模型和视图名发送回DispatcherServlet 4️⃣。

7. 这样，控制器就不会与特定的视图相耦合，传递给DispatcherServlet的视图名并不直接表示某个特定的 JSP。实际上，他甚至并不能确定视图就是 JSP。相反，它仅仅传递了一个逻辑名称，这个名字将会用来查找产生结果的真正视图。DispatcherServlet将会使用视图解析器（view resolver）5️⃣来将逻辑视图名匹配为一个特定的视图实现，它可能是也可能不是 JSP。

8. 既然DispatcherServlet已经知道由哪个视图渲染结果，那请求的任务基本上也就完成了。它的最后一站是视图的实现（可能是 JSP）6️⃣，在这里它交付模型数据。请求的任务就完成了。视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端（浏览器）（不会像听上去那样硬编码）7️⃣。

可

以看到，请求要经过很多的步骤，最终才能行程返回给客户端的响应。大多数的步骤都是在 Spring框架内部完成的，也就是上图所示的组件中。