Spring MVC 学习起步--Spring MVC简介及请求处理流程

工作了几年，没有写过底层框架也没有写过比较纯粹的工具类，其实说起来挺丢人的，呵呵，从接触java开始就是做的web项目，其实现在八成的程序员应该都在为企业级web应用程序敲代码。说到web应用就不得不说Spring MVC，当然，说道Spring MVC就不得不说一个MVC设计模式，前两年面试的时候经常被问道。使用了Spring MVC 这么几年，都没有好好的梳理过，是时候来总结一下了。

一、MVC设计模式

MVC是Model、View、Control的简称。分别代表M-数据模型、V-用户界面、C-控制器。
1.Model-数据模型
数据模型是指抽象的业务规则以及系统数据。一般在系统中主要用来对应数据库以及数据在视图层的展示，也就是平常我们代码中所说的Entity。
2.View-用户界面
用户界面通俗点讲就是用户操作数据的浏览器展示页面，用户可以通过页面来对具体的数据操作。
3.Control-控制器
控制器存在的主要作用就是保证V与M的数据同步，页面用户操作了，需要将信息传给M从而进一步操作数据库，相反M的数据发生变化，视图也要随之更新

面试的时候除了问MVC分别代表什么之外就是使用MVC结构的好处了。MVC的主要优点就是将数据模型与用户界面分层，由于M与V分离，那么控制器就可以连接不同的M与V组成Web项目，也就是说同样的业务，可以用多种视图表示而不需要修改M层的代码，反之亦是如此。

二、Spring MVC是什么

Spring MVC 是一种基于java实现了web MVC设计模式的请求驱动类型的轻量级web框架，即使用了MVC架构的思想，将web进行职责解耦，基于请求驱动指的就是使用请求-响应模式。现在比较主流的应该就Spring mvc 跟struts2了，不过个人觉得还是spring mvc更好用。

三、Spring MVC处理请求的流程

一般简历上写熟悉或者熟练使用Spring mvc的，面试的时候基本都会被问到Spring mvc处理请求的整个流程，其实也没那么复杂，一开始的时候也回答不出来，都是面试前背的，但是结合图，可以再跟现实中的一些实际例子对比一下，就好记忆了。

从图中也可以看出整个流程的核心就是DispatcherServlet，为了加深印象，就可以把DispatcherServlet比作一个报社的秘书部，可能报社没有这个部门，呵呵，为了加深理解自己创建一个报社吧，里面有好几个主编分别负责不同类型的文章。假设某位作家向改报社投稿了正常的处理流程是：
1.请求到达DispatcherServlet，DispatcherServlet需要只要将请求发送给哪个控制器（主编），所以DispatcherServlet会查询一个或多个处理器映射（工作职责表）来确定请求下一站在哪里。处理映射器会根据请求所携带的url信息来进行决策（也就是秘书部需要根据投稿的类型来确定这篇文章应该由哪个主编来审阅）
2.一旦选择了合适的控制器（也就是文章找到了对应的主编），DispatcherServlet会将请求发送给对应的控制器，到了控制器，请求就会卸下其负载（用户提交的信息）并耐心等待控制器处理这些信息（文章给了主编，怎么处理就是主编的事情了）。
3.控制器在完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户，并在浏览器上显示（也就是主编看完后经常会有一些意见，最后要回信给投稿的作家）。
4.控制器所做的最后一件事就是将模型数据打包，并标出用于渲染的视图名，它接下来将请求连同模型和视图名发回给DispatcherServlet（主编也好意见，但是说要用一个中国风的信封，然后就把回信和需要的信封名告诉了秘书部）
5.传送给DispatcherServlet的视图名并不直接表示某个特定的jsp，实际上它甚至不确定视图就是jsp，相仿它仅仅传递了一个逻辑名称，这个名称将会用来查找产生结果的真正视图（秘书只是知道中国风信封，哪里有他也不知道，要去邮局查）
6.DispatcherServlet将会拿着返回的视图名去视图解析器中匹配一个特定是视图实现，他可能是也可能不是jsp（去邮局查到了中国风的信封）
7.DispatcherServlet已经知道了由哪个视图渲染结果，那请求的任务基本也就完成了，最后一站就是视图实现，需要使用的数据在DispatcherServlet中。渲染结束，视图将通过响应返回给用户（将回信和信封组装，邮回给投稿者）。

虽然举例可能不是很恰当，但是可以借助现实中的流程加深一下Spring MVC的流程记忆。先大概总结一下，后面再深入总结一下Spring MVC的具体使用