一个Web请求的“自由之路”---《Spring实战》系列 06

叮铃铃，从今天这篇开始，我们就正式进入《Spring实战》的第二部分了，Spring中的Web 。从名字中也可以看出来，这部分要介绍的内容，通通和web相关。

不信你看这标题：第五章“构建Spring Web应用程序”，第六章“渲染Web视图”，第七章“Spring MVC的高级技术”，第八章“使用Spring web Flow”，是不是全和Web相关？没错，接下来，我们就要看看Web是如何和Spring如胶似漆的缠绵在一起了。画面很美，请不要眨眼，系好安全带，我们这就出发。

今天先来看一看一个Web请求的“自由之路”。

基于Web的应用程序，对于我们Java开发人员来说，应该是司空见惯了。但是，这里面也有一些常见的棘手的问题，比如说，状态管理，工作流，以及验证都是需要解决的问题，而且HTTP协议的无状态性决定了这些问题都不那么容易解决。

但是，Spring中的Web框架，更准确地说Spring MVC （Model-view-Controller，MVC）模型-视图-控制器，完美的帮助了Spring框架来实现灵活和松耦合的Web应用程序。

有了Spring MVC, 一个Web请求之路才变得更加丰富多彩。我们一起来看看它是如何从客户端发起，经过Spring MVC中的组件，最终再返回到客户端的完整历程。

请仔细看下面这张图，箭头所指的方向就是一个Web请求所要走过的自由之路。

这个请求首先从客户端发出，就像一个皮球一样被踢到DispatcherServlet这里，它是第一站，在SpringMVC中被称为前端控制器，主要作用就是控制这个请求的走向。

你看上面的图里就它身上背负的箭头最多，因为每当这个请求被踢出去一次，下次就要被踢回来，然后再由前端控制器踢到其它组件里面去。每个组件负责的任务都不一样。

比如说处理器映射，当请求到达前端控制器后，处理器映射就是请求要去的第二站，在这里处理器映射会根据请求中所携带的URL信息来进行决策。一旦选择了合适的控制器，前端控制器就会把请求发送给选中的控制器。

到达控制器后，请求就会耐心的等待，把用户提交的信息一五一十的告诉控制器，并等待它处理好这些信息。当控制器处理完这些信息后，会产生一些信息，这些信息需要返回给用户并在浏览器显示。这些信息就被称为模型（model）。

但是呢，这些都是非常原始的信息，直接返回给用户看实在太丑了，本着用户友好的原则，一般会进行格式化，也就是用HTML装饰一下，所以这些信息需要发送给一个视图（View）,通常会是JSP。然后控制器会将模型数据打包，并且标示出用于渲染输出的视图名。

然后就会将请求连同模型和视图名一起发送给前端控制器。这样做的好处就是：控制器不会与特定的视图相耦合，传递给前端控制器的视图名并不直接表示某个特定的JSP，而仅仅是一个逻辑名称。

前端控制器会通过这个逻辑名称去寻找真正的视图，并且会使用视图解析器（view resolver）来将逻辑视图匹配为一个特定的视图实现。所以请求的最后一站就是视图的实现（可能是JSP）,在这里它交付模型数据，请求的任务就完成了。

视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端。到这里，一个Web请求的自由之路就结束了。

以上就是这一章的重点内容，同时也是面试题中面试官最爱问的问题之一，记住web请求的自由之路，以后再碰到这样的面试题就不用怕了。

这章剩下的内容就是如何在代码里配置前端控制器和视图，在这里就不做详细的解释了，先理解它背后的实现原理，再去写代码就会更加得心应手了。

这就是一个Web请求的“自由之路”，看似自由，实则每一个阶段都有自己要完成的任务，它无法选择，也无法逃避，只能勇往直前。

就像我们的人生一样，在每个阶段都有自己要完成的使命，在年轻的年纪，就要拼搏奋斗，只有这样，才能在快走完这条“自由之路”之时，笑谈人生呐~