MVC简介，SpringMVC简介及基本流程

 

MVC简介

MVC (Model-View-Controller,模型-视图-控制器)在当今Java界尤其是Web开发领域已经是耳熟能详的一个名词了。

如图所示,最初意义上的MVC模式中,各个组件的作用如下所述。

控制器负责接收视图发送的请求并进行处理,它会根据请求条件通知模型进行应用程序状态的更新,之后选择合适的视图显示给用户。

模型通常封装了应用的逻辑以及数据状态。当控制器通知模型进行状态更新的时候,模型封装的相应逻辑将被调用。执行完成后,模型通常会通过事件机制通知视图状态更新完毕,从而视图可以显示最新的数据状态。

视图是面向用户的接口。当用户通过视图发起某种请求的时候,视图将这些请求转发给控制器进行处理。处理流程流经控制器和模型之后,最终视图将接收到模型的状态更新通知,然后视图将结合模型数据,更新自身的显示。

可见,最初意义上的MVC模式,在视图与模型间的数据同步工作是采用从模型Push到视图的形式完成的。而对于Web应用来说,局限于所用的协议以及使用场景,无法实现从模型Push数据到视图这样的功能。所以,我们只能对MVC中的组件的最初作用定义做适当的调整。

由控制器与模型进行交互,在原来通知模型更新应用程序状态的基础上,还要获取模型更新的结果数据,然后将更新的模型数据一并转发给视图。也就是说,我们现在改由控制器从模型中Pull数据给视图,这种意义上的MVC称为Web MVC,也就是现在大多web的架构模式。

Spring MVC流程简介

Spring MVC框架的处理控制器的实现策略，与其他的请求驱动的Web框架在总体思路上是相似 的，就如我们之前所说的那样，通过引入Front Controller和Page Controller的概念来分离流程控制逻辑 与具体的Web请求处理逻辑。org.springframework.web.servlet.DispatcherServlet就是 SpringMVC框架中的Front Controller, 它负责接收并处理所有的Web请求。

只不过针对具体的处理逻辑， 它会委派给它的下一级控制器去实现，即org.springframework. web. servlet .mvc. Controller, 而 org.springframework.web.servlet. mvc.Controller则对应Page Controller的角色定义，具体关 系如图所示。

当然，只有它们两个还远远称不上一个完整的Web开发框架，要使得整个的Web开发框架能够运 作起来，我们还需要更多的角色相助。下面，让我带你走过DispatcherServlet这道长廊，井乘机一 一介绍SpringMVC中的各位“掌权者”。

在我们开始Dispatcherservlet的旅程之前，不妨先回顾一下控制器Servlet常会做哪些工作。

就以我们JSPModel2架构中提到的MockMagicServlet为例，它在处理Web 请求的过程中所做的工作，我们可以简单归纳为如下三点。

获取请求信息，比如请求的路径、各种参数值等，如下所示：

根据请求信息，调用具体的服务对象处理具体的Web请求，如下所示：

处理完成后，将要在视图中显示的模型数据通过request进行传递，最后通过Request­Dispatcher选择具体的jsp视图井显示，如下所示：

有了以上Mock.MagicServlet处理流程的剖析作为基础，现在我们再来看Dispatcherservlet 在整个Web请求处理过程中所做的事情，就会发现，DispatcherServlet在实现上并没有太多不同 或者说改变，唯一的差异或者改变是，DisPatcherServlet将各项工作细化并分离给了较为独立的角色来完成。

DispatcherServlet的处理流程。可以简单概括如下。

HandlerMapping先生(Web请求的处理协调人）

既然DispatcherServlet是整个框架的FrontController, 当将它注册到web.xml时，就注定了它要 服务于规定的一组Web请求的命运而不是单独的一个Web请求。代码清单是DispatcherServlet 注册到web.xml配贾文件的通常示例。

不能够像“一个Web请求对应一个Servlet"那样获取Web容器对URL映射匹配的支持，Dispat­cherServlet现在只好自己来处理具体的Web请求和具体的处理类之间的映射关系匹配了。

对于Web请求与具体的处理类之间的映射匹配来说，具体的处理方式或者说策略可能多种多样， 完全可能随着应用程序，甚至每个具体的Web请求的不同而发生变化，如下所述。

最常见的就是，那种“抬头去尾＂的处理方式，将Web请求的URL路径去除前面的上下文路径 (context path)和最后的扩展名，取最终剩下的路径信息，作为匹配的结果。比如，如下代码 将最终以resource作为匹配结果。

http://www.nosuchname.com/yourapp/resource.html

以Web请求的URL中存在的某个参数的值作为匹配的标准。比如，当发现请求的路径中存在 controller这个参数的话，其值就会被作为匹配结果用来调用具体的处理类，对于如下所示 的URL:

http://www.nosuchname.com/yourapp/resource.htm?controller=yourController

匹配的结果就是yourController。

以cookie或者session中的某些信息作为匹配标准。比如，针对某个客户的Web请求，全部转发 给一个处理类进行处理。

甚至于，结合Ruby On Rails的理念，我们在开发中规定一些惯例或者说约定，然后以这些惯例或 者约定来解析Web请求的URL路径信息，以获取具体的处理类匹配。可见，要将映射匹配的逻辑写死 到DispatcherServlet, 是无法有效扩展的，而且匹配的方式也可能随着需求而变化。

所以，SpringMVC 为了能够灵活地处理映射的匹配，引入了org.springframework.Web.servlet.HandlerMapping 来专门管理Web请求到具体的处理类之间的映射关系。在Web请求到达DispatcherServlet之后， Dispatcher将寻求具体的HandlerMapping实例，以获取对应当前Web请求的具体处理类，即 org.springframework.web.servlet.Controller。

org.springframework.Web.servlet.Controller(Web请求的具体处理者）

org.springframework.Web.servlet.Controller是对应DispatcherServlet的次级控 制器，它本身实现了对应某个具体Web请求的处理逻辑。

在我们所使用的HandlerMapping查找