因为开始学习Spring框架有点晚，所以一直在赶进度，没来得及写博客记录学习过程，确实是一个遗憾吧！本来这种东西遗忘率就挺高的，所以，必须多总结．现在的话．已经学习到＜Spring实战＞这本书的第二部分了，也就是Ｗeb中的Spring.所以就边学边抽时间总结吧，至于前面没来得及总结的第一部分，我打算在利用空闲时间尽快补起来．
参考书籍：＜Spring实战＞（第四版）
Spring通常是用来开发Web应用的．我们会使用Spring的MVC框架来为应用程序添加Web前端部分．
在学习构建Spring Web应用程序之前，先来了解以下Spring MVC的起步吧！
Spring MVC起步
Spring MVC基于模型－视图－控制器模式实现．
M－－－－Ｍodel 模型
V －－－－View 视图
C－－－－Controller 控制器
Spring MVC可以帮助我们构建像Spring框架那样灵活又松耦合的Web应用程序．
先来简单看一下请求是怎么从客户端发起，经过Spring MVC中的组件，最终返回到客户端的．
跟踪Spring MVC的请求
当用户在Web浏览器中点击链接或者提交表单时，请求就开始工作了．请求工作十分繁忙，它从离开浏览器开始到获取响应返回，经过了很多个站点，并且在每站都会留下一些信息同时也会带上其他信息．
如下图展示了请求使用Spring MVC所经历的所有站点．
在请求离开浏览器时，会带有用户所请求内容的信息，至少会包含请求的URL.但是还可能带有其他的信息，例如，用户提交的表单信息．
来看看请求旅程中的所有站点．
对照上图来理解请求的全过程会发现十分简单，来看看吧．
第一站：Spring的DispatcherServlet.
与大多数基于Java的Web框架一样，Spring MVC所有的请求都会通过一个前端控制器(front controller) Servlet.前端控制器是常用的Web应用程序模式，在这里一个单实例的Servlet将请求委托给应用程序的其他组件来执行实际的处理．
Spring MVC中，DispatcherServlet就是前端控制器．
DispatcherServlet的任务是将请求发送给Spring MVC控制器(controller).控制器是一个用于处理请求的Spring组件．在典型的应用程序中可能不止有一个控制器，所以DispatcherServlet需要知道应该将请求发送给哪个控制器，所以呢？就来到了第二站．
第二站：处理器映射
DispatcherServlet会查询一个或多个处理器映射(hander mapping)来确定请求的下一站在哪里．处理器映射会根据请求所携带的URL信息来进行决策．
选择好合适的处理器后，DispatcherServlet就会把请求发送给选择好的控制器，即到达了第三站．
第三站：控制器
请求到达了控制器，就会卸下其负载(用户提交的信息)并耐心等候控制器处理这些信息．控制器完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户并且在浏览器上面显示．这些信息就叫做模型(model)．
不过，给用户仅仅返回这些信息是不够的，这些信息需要以用户友好的方式进行格式化，一般会是HTML,所以，信息需要发送给一个视图(view)，通常会是jsp.
控制器做的最后一件事是将模型数据打包，并且标示出用于渲染输出的视图名，即来到第四站．
第四站：将请求连同模型和视图名发送回DispatcherServlet
这样的话，控制器就不会与特定的视图相耦合，传递给DispatcherServlet的视图名并不直接表示某个特定的JSP. 实际上，它甚至不能确定视图就是JSP．相反的，它仅仅传递了一个逻辑名称，这个名字将会被用来查找产生结果的真正视图，这时候，需要用到视图解析器，自然而然的来到了第五站．
第五站：视图解析器
DispatcherServlet使用视图解析器(view resolver)来将逻辑视图名匹配为一个特定的视图实现，它可能是也可能不是JSP.
走到这里，DispatcherServlet已经知道了由哪个视图渲染结果，那么请求的任务基本上就算完成了，最后，当然是去实现视图了呀．
第六站：视图的实现
在这里它交付模型数据，请求的任务就算是完成了．视图将使用模型数据渲染输出．
第七站：响应
上一站中，使用模型数据渲染输出的视图会通过响应对象传递给客户端，即进行最终的响应．好啦，一个完整的请求旅程算是结束啦!