MVC框架详解（资源整理）

一、什么是MVC？
MVC是三个单词的首字母缩写，它们是Model（模型）、View（视图）和Controller（控制）。

1、视图

视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

2、模型

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

3、控制

控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能

   1）最上面的一层，是直接面向最终用户的"视图层"（View）。它是提供给用户的操作界面，是程序的外壳。
   2）最底下的一层，是核心的"数据层"（Model），也就是程序需要操作的数据或信息。
   3）中间的一层，就是"控制层"（Controller），它负责根据用户从"视图层"输入的指令，选取"数据层"中的数据，然后对其进行相应的操作，产生最终结果。

这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。这样一来，软件就可以实现模块化，修改外观或者变更数据都不用修改其他层，大大方便了维护和升级。

二、SpringMVC流程图详解
         要把SpringMVC流程图搞明白，首先需要先搞明白6个组件
        1.DisPatcherServlet 前端控制器
核心。用户在浏览器输入url，发起请求，首先会到达DisPatcherServlet，由它来调用其他组件来配合工作的完成，DisPatcherServlet的存在大大降低了组件之间的耦合性
        2.HandlerMapping 处理器映射器
记录url与处理器的映射，方式有注解、XML配置等
        3.HandLer 处理器
后端控制器（通俗一点：Controller层所写的业务代码）。对用户的请求进行处理
       4.HandlerAdapter 处理器适配器
通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。（我也不太明白）
       5.ViewResolver 视图解析器
ViewResolver负责解析view视图，并进行渲染（数据填充），将处理结果通过页面展示给用户看
       6.View 视图
View是一个接口，实现类支持不同的View类型（jsp、freemarker、velocity）
一般情况下需要通过页面标签或者页面模板技术将模型数据通过页面展示给用户，需要由程序员根据业务需求开发具体的页面。

【流程图说明】

1.用户发送请求至前端控制器DispatcherServlet。

2.前端控制器DispatcherServlet收到请求后调用处理器映射器HandlerMapping。

3.处理器映射器HandlerMapping根据请求的Url找到具体的处理器，生成处理器对象Handler及处理器拦截器HandlerIntercepter（如果有则生成）一并返回给前端控制器DispatcherServlet。

4.前端控制器DispatcherServlet通过处理器适配器HandlerAdapter调用处理器Controller。

5.执行处理器（Controller，也叫后端控制器）

6.处理器Controller执行完后返回ModelAnView。

7.处理器映射器HandlerAdapter将处理器Controller执行返回的结果ModelAndView返回给前端控制器DispatcherServlet。

8.前端控制器DispatcherServlet将ModelAnView传给视图解析器ViewResolver。

9.视图解析器ViewResolver解析后返回具体的视图View。

10.前端控制器DispatcherServlet对视图View进行渲染视图（即：将模型数据填充至视图中）

11.前端控制器DispatcherServlet响应用户。

三、简单例子
1.首先是用户发送请求，比如在浏览器中输入http://localhost:8080/SpringTest/login

2.用户的请求就发送到了DispatcherServlet也就是前端控制器，这个东西是一个Servlet的实现，用来干什么呢？用来接收用户的请求，然后响应结果，相当于一个转发器，它的配置如下

<servlet>
 <servlet-name>springMVC</servlet-name>
 <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 <init-param>
 <param-name>contextConfigLocation</param-name>
 <param-value> classpath:springMVC-servlet.xml</param-value>
 </init-param>
 <load-on-startup>1</load-on-startup>
 </servlet>
 
 <servlet-mapping>
 <servlet-name>springMVC</servlet-name>
 <url-pattern>/</url-pattern>
 </servlet-mapping>
如果翻开DispatcherServlet源码的话，会发现会默认加载SpringMVC的一些配置，源码如下

static {
 // Load default strategy implementations from properties file.
 // This is currently strictly internal and not meant to be customized
 // by application developers.
 try {
 ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
 defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
 }
 catch (IOException ex) {
 throw new IllegalStateException("Could not load 'DispatcherServlet.properties': " + ex.getMessage());
 }
 }
并且该servlet也会默认加载默认DispatcherServlet会加载WEB-INF/[DispatcherServlet的Servlet名字]-servlet.xml配置文件。本示例为WEB-INF/SpringMVC-servlet.xml.此配置文件就用来配置后面的处理映射器、处理适配器等相关信息

3.经过DispatcherServlet过滤后URL后，比如上述的URL是http://localhost:8080/SpringTest/login，那么这时候就进入到了HandleMapping也就是映射处理器。这是用来干什么的呢？就是用来根据URL来匹配我们的处理器（或者就做控制器），比如我们请求的路径最后结尾的字母是login，那么让那个控制器来为我们服务呢？这时候就靠HandleMapping来处理了。下面列一下SpringMVC中的几种处理映射器。

3.1 BeanNameUrlHandlerMapping：用来根据控制器的name属性来匹配要处理的映射器，配置如下

<bean id="itemsController1" name="/queryItems_test.action"
class="cn.ssm.controller.ItemsController1" />
 

<bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping" />

 经过这样配置的话，就可以通过/queryItems_test来查找我们的控制器了

3.2 SimpleUrlHandlerMapping：根据URL来映射匹配

<bean id="itemsController1" name="/queryItems_test.action"
class="cn.ssm.controller.ItemsController1" />
 
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="mappings">
 <props>
 
 <prop key="/queryItems1.action">itemsController1</prop>
 <prop key="/queryItems2.action">itemsController1</prop>
 <prop key="/queryItems3.action">itemsController2</prop>
 </props>
 </property>
 </bean>
3.3 RequestMappingHandlerMapping：3.1后引入的新的特性，注解适配器，直接通过Controller标签即可识别

<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">

4.接着向下走，通过映射处理器就找到了我们需要处理用户请求的控制器也就是Handler，那么此时还需要HandlerAdapter（处理器适配器）来，作用就是要按照特定规则（HandlerAdapter要求的规则）去执行Handler。常见的适配器如下

4.1 SimpleControllerHandlerAdapter：要求handler实现Controller接口

SimpleControllerHandlerAdapter将会调用处理器的handleRequest方法进行功能处理，该处理方法返回一个ModelAndView给DispatcherServlet；当然了也有对应的注解适配器

4.2 HttpRequestHandlerAdapter：要求编写的Handler实现HttpRequestHandler接口

4.3.注解适配器有RequestMappingHandlerAdapter，用来配合注解的开发

5.接着向下走，经过适配器调用控制器的方法后，就会想前端控制器返回一个ModelView，包含我们需要信息的pojo对象和视图信息。

6.前端控制器开始解析视图信息，通过视图解析器（View Resolver），进行视图解析，根据逻辑视图名解析成真正的视图（view）。如下配置

<bean
 class="org.springframework.web.servlet.view.InternalResourceViewResolver">
 
 <property name="prefix" value="/WEB-INF/jsp/"/>
 
 <property name="suffix" value=".jsp"/>
 </bean>
8.最后一部操作了，解析完视图信息后，就把modelview中的model信息传递到我们的view界面上，整个流程就处理完毕。

四、常用注解总结

*** @RequestMapping(): 映射请求[为控制器指定可以处理哪些URL请求]

使用请求URL、请求方法、请求参数、请求头映射请求,它们之间是与的关系，联合使用让请求更加精细化。

[value、method、params 、heads]

params和heads支持简单的表达式

① param1表示请求必须包含名为param1的请求

② ！param1 表示请求不能包含名为param1的请求

③ param1！= value1 表示请求包含名为param1的参数，但其值不能为

举例：

@RequestMapping(value="/delete",method=RequestMethod.POST, params="userId",heads="contentType=text/*")

@RequestMapping还支持ant风格的资源地址：

① ？匹配文件名中的一个字符

② * 匹配文件名中的任意字符

③ ** 匹配多层路径

举例：

/user/createUser??: 匹配

/user/createUseraa、/user/createUserbb等 URL

/user/*/createUser:匹配

/user/aaa/createUser、/user/bbb/createUser 等 URL

/user/**/createUser: 匹配

/user/createUser、/user/aaa/bbb/createUser 等 URL

*** @PathVariable(): 映射URL绑定的占位符

通过 @PathVariable 可以将URL中占位符参数绑定到控制器处理方法的入参中，URL中{ xxx }占位符可以通过@PathVariable("xxx")绑定到操作方法的入参中。

   举例：
      @RequestMapping(value="/delete/{id}")
      public Stringdelete(@PathVariable("id")Integer id){
      }

*** @RequestParam(): 绑定请求参数值
在处理方法入参处使用 @RequestParam 可以把请求参数传递给请求方法
value：参数名 required：是否必须。默认为 true

举例：
@RequestMapping("/get")

public Stringget(@RequestParam(value="userName",required=true) String name){

return "seccess";

}

备注：如果页面中的请求参数的名字和形参的名字一致的话，没必要用该注解。

*** @RequestHeader(): 绑定请求头的属性值
   通过 @RequestHeader 即可将请求头中的属性值绑定到处理方法的入参中
   举例：
      @RequestMapping("/get")
      public Stringget(@RequestHeader("Accept-Encoding") String encoding){
           return"seccess";
      }

*** @CookieValue()
   使用@CookieValue 绑定请求中的Cookie值，可让处理方法入参绑定某个Cookie值
   举例：
      @RequestMapping("/get")

public String get(@CookieValue(value="sessionId",required=false)StringsessionId){

return “success”

}

*** @SessionAttributes()
若希望在多个请求之间共用某个模型属性数据，则可以在控制器类上标注此注解。

标注一个@SessionAttributes, Spring MVC 将在模型中对应的属性暂存HttpSession中，@SessionAttributes除了可以通过属性名指定需要放到会话中的属性外，还可以通过模型属性的对象类型指定哪些模型属性需要放到会话中 @SessionAttributes(types=User.class)

会将隐含模型中所有类型为User.class 的属性添加到会话中

@SessionAttributes(value={“user1”, “user2”})

@SessionAttributes(types={User.class, Dept.class})

@SessionAttributes(value={“user1”,“user2”},types={Dept.class})

举例：

@SessionAttributes("user")

@Controller

@RequestMapping("/get")

      publicString get(){
      @ModelAttribute("user")
      public User getUser(){
         User user = new User();
         user.setAge(10);

return user;
 }
 @ModelAttribute("/get1")
 public Userget1(@ModelAttribute("user") User user){
 user.setAget(22);
 return"success";
 }
 @ModelAttribute("/get1")
 public User get1(Map<Sting,Object> map,SessionStatussessionStatus){
 User user =map.get("user");
 user.setId(1000);
 return"success";
 }
 }

*** @ModelAttribute()

在方法定义上使用@ModelAttribute（），SpringMVC在调用目标处理方法前，会先逐个调用在方法级上标注了@ModelAttribute的方法,在方法的入参前使@ModelAttribute()可以从隐含对象中获取隐含的模型数据中获取对象，再将请求参数绑定到对象中，再传入入参将方法入参对象添加到模型中。

五、MVC优点与不足
MVC的优点:
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。

首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。

再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。

控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。

最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。

MVC的不足

MVC的不足体现在以下几个方面：

（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

来源：CSDN

作者：q12332455

链接：https://blog.csdn.net/q12332455/article/details/102973852