大家好，我是CSDN的博主ThinkWon，“2020博客之星年度总评选"开始啦，希望大家帮我投票，每天都可以投多票哦，点击下方链接，然后点击"最大”，再点击"投TA一票"就可以啦！

投票链接：https://bss.csdn.net/m/topic/blog_star2020/detail?username=thinkwon

在技术的世界里，ThinkWon将一路与你相伴！创作出更多更高质量的文章！2020为努力奋斗的你点赞👍，️新的一年，祝各位大牛牛气冲天，牛年大吉！😊😊

文章目录
概述
什么是Spring MVC？简单介绍下你对Spring MVC的理解？
Spring MVC的优点
核心组件
Spring MVC的主要组件？
什么是DispatcherServlet
什么是Spring MVC框架的控制器？
Spring MVC的控制器是不是单例模式,如果是,有什么问题,怎么解决？
工作原理
请描述Spring MVC的工作流程？描述一下 DispatcherServlet 的工作流程？
MVC框架
MVC是什么？MVC设计模式的好处有哪些
常用注解
注解原理是什么
Spring MVC常用的注解有哪些？
SpingMvc中的控制器的注解一般用哪个,有没有别的注解可以替代？
@Controller注解的作用
@RequestMapping注解的作用
@ResponseBody注解的作用
@PathVariable和@RequestParam的区别
其他
Spring MVC与Struts2区别
Spring MVC怎么样设定重定向和转发的？
Spring MVC怎么和AJAX相互调用的？
如何解决POST请求中文乱码问题，GET的又如何处理呢？
Spring MVC的异常处理？
如果在拦截请求中，我想拦截get方式提交的方法,怎么配置
怎样在方法里面得到Request,或者Session？
如果想在拦截的方法里面得到从前台传入的参数,怎么得到？
如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象？
Spring MVC中函数的返回值是什么？
Spring MVC用什么对象从后台向前台传递数据的？
怎么样把ModelMap里面的数据放入Session里面？
Spring MVC里面拦截器是怎么写的
介绍一下 WebApplicationContext

Java面试总结汇总，整理了包括Java基础知识，集合容器，并发编程，JVM，常用开源框架Spring，MyBatis，数据库，中间件等，包含了作为一个Java工程师在面试中需要用到或者可能用到的绝大部分知识。欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，在此表示感激不尽。文章持续更新中…




序号
内容
链接地址




1
Java基础知识面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104390612


2
Java集合容器面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104588551


3
Java异常面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104390689


4
并发编程面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104863992


5
JVM面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104390752


6
Spring面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397516


7
Spring MVC面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397427


8
Spring Boot面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397299


9
Spring Cloud面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397367


10
MyBatis面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/101292950


11
Redis面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/103522351


12
MySQL数据库面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104778621


13
消息中间件MQ与RabbitMQ面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104588612


14
Dubbo面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104390006


15
Linux面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104588679


16
Tomcat面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397665


17
ZooKeeper面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104397719


18
Netty面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/104391081


19
架构设计&分布式&数据结构与算法面试题（2020最新版）
https://thinkwon.blog.csdn.net/article/details/105870730


概述
什么是Spring MVC？简单介绍下你对Spring MVC的理解？
Spring MVC是一个基于Java的实现了MVC设计模式的请求驱动类型的轻量级Web框架，通过把模型-视图-控制器分离，将web层进行职责解耦，把复杂的web应用分成逻辑清晰的几部分，简化开发，减少出错，方便组内开发人员之间的配合。
Spring MVC的优点
（1）可以支持各种视图技术,而不仅仅局限于JSP；
（2）与Spring框架集成（如IoC容器、AOP等）；
（3）清晰的角色分配：前端控制器(dispatcherServlet) , 请求到处理器映射（handlerMapping), 处理器适配器（HandlerAdapter), 视图解析器（ViewResolver）。
（4） 支持各种请求资源的映射策略。
核心组件
Spring MVC的主要组件？
（1）前端控制器 DispatcherServlet（不需要程序员开发）
作用：接收请求、响应结果，相当于转发器，有了DispatcherServlet 就减少了其它组件之间的耦合度。
（2）处理器映射器HandlerMapping（不需要程序员开发）
作用：根据请求的URL来查找Handler
（3）处理器适配器HandlerAdapter
注意：在编写Handler的时候要按照HandlerAdapter要求的规则去编写，这样适配器HandlerAdapter才可以正确的去执行Handler。
（4）处理器Handler（需要程序员开发）
（5）视图解析器 ViewResolver（不需要程序员开发）
作用：进行视图的解析，根据视图逻辑名解析成真正的视图（view）
（6）视图View（需要程序员开发jsp）
View是一个接口， 它的实现类支持不同的视图类型（jsp，freemarker，pdf等等）
什么是DispatcherServlet
Spring的MVC框架是围绕DispatcherServlet来设计的，它用来处理所有的HTTP请求和响应。
什么是Spring MVC框架的控制器？
控制器提供一个访问应用程序的行为，此行为通常通过服务接口实现。控制器解析用户输入并将其转换为一个由视图呈现给用户的模型。Spring用一个非常抽象的方式实现了一个控制层，允许用户创建多种用途的控制器。
Spring MVC的控制器是不是单例模式,如果是,有什么问题,怎么解决？
答：是单例模式,所以在多线程访问的时候有线程安全问题,不要用同步,会影响性能的,解决方案是在控制器里面不能写字段。
工作原理
请描述Spring MVC的工作流程？描述一下 DispatcherServlet 的工作流程？
（1）用户发送请求至前端控制器DispatcherServlet；

（2） DispatcherServlet收到请求后，调用HandlerMapping处理器映射器，请求获取Handle；

（3）处理器映射器根据请求url找到具体的处理器，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet；

（4）DispatcherServlet 调用 HandlerAdapter处理器适配器；

（5）HandlerAdapter 经过适配调用 具体处理器(Handler，也叫后端控制器)；

（6）Handler执行完成返回ModelAndView；

（7）HandlerAdapter将Handler执行结果ModelAndView返回给DispatcherServlet；

（8）DispatcherServlet将ModelAndView传给ViewResolver视图解析器进行解析；

（9）ViewResolver解析后返回具体View；

（10）DispatcherServlet对View进行渲染视图（即将模型数据填充至视图中）

（11）DispatcherServlet响应用户。

MVC框架
MVC是什么？MVC设计模式的好处有哪些
mvc是一种设计模式（设计模式就是日常开发中编写代码的一种好的方法和经验的总结）。模型（model）-视图（view）-控制器（controller），三层架构的设计模式。用于实现前端页面的展现与后端业务数据处理的分离。
mvc设计模式的好处
1.分层设计，实现了业务系统各个组件之间的解耦，有利于业务系统的可扩展性，可维护性。
2.有利于系统的并行开发，提升开发效率。
常用注解
注解原理是什么
注解本质是一个继承了Annotation的特殊接口，其具体实现类是Java运行时生成的动态代理类。我们通过反射获取注解时，返回的是Java运行时生成的动态代理对象。通过代理对象调用自定义注解的方法，会最终调用AnnotationInvocationHandler的invoke方法。该方法会从memberValues这个Map中索引出对应的值。而memberValues的来源是Java常量池。
Spring MVC常用的注解有哪些？
@RequestMapping：用于处理请求 url 映射的注解，可用于类或方法上。用于类上，则表示类中的所有响应请求的方法都是以该地址作为父路径。
@RequestBody：注解实现接收http请求的json数据，将json转换为java对象。
@ResponseBody：注解实现将conreoller方法返回对象转化为json对象响应给客户。
SpingMvc中的控制器的注解一般用哪个,有没有别的注解可以替代？
答：一般用@Controller注解,也可以使用@RestController,@RestController注解相当于@ResponseBody ＋ @Controller,表示是表现层,除此之外，一般不用别的注解代替。
@Controller注解的作用
在Spring MVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在Spring MVC 中提供了一个非常简便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用@RequestMapping 和@RequestParam 等一些注解用以定义URL 请求和Controller 方法之间的映射，这样的Controller 就能被外界访问到。此外Controller 不会直接依赖于HttpServletRequest 和HttpServletResponse 等HttpServlet 对象，它们可以通过Controller 的方法参数灵活的获取到。
@Controller 用于标记在一个类上，使用它标记的类就是一个Spring MVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是Spring MVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式：

在Spring MVC 的配置文件中定义MyController 的bean 对象。
在Spring MVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。

@RequestMapping注解的作用
RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。
RequestMapping注解有六个属性，下面我们把她分成三类进行说明（下面有相应示例）。
value， method
value：   指定请求的实际地址，指定的地址可以是URI Template 模式（后面将会说明）；
method： 指定请求的method类型， GET、POST、PUT、DELETE等；
consumes，produces
consumes： 指定处理请求的提交内容类型（Content-Type），例如application/json, text/html;
produces:  指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回；
params，headers
params： 指定request中必须包含某些参数值是，才让该方法处理。
headers： 指定request中必须包含某些指定的header值，才能让该方法处理请求。
@ResponseBody注解的作用
作用： 该注解用于将Controller的方法返回的对象，通过适当的HttpMessageConverter转换为指定格式后，写入到Response对象的body数据区。
使用时机：返回的数据不是html标签的页面，而是其他某种格式的数据时（如json、xml等）使用；
@PathVariable和@RequestParam的区别
请求路径上有个id的变量值，可以通过@PathVariable来获取 @RequestMapping(value = “/page/{id}”, method = RequestMethod.GET)
@RequestParam用来获得静态的URL请求入参   spring注解时action里用到。
其他
Spring MVC与Struts2区别
相同点
都是基于mvc的表现层框架，都用于web项目的开发。
不同点
1.前端控制器不一样。Spring MVC的前端控制器是servlet：DispatcherServlet。struts2的前端控制器是filter：StrutsPreparedAndExcutorFilter。
2.请求参数的接收方式不一样。Spring MVC是使用方法的形参接收请求的参数，基于方法的开发，线程安全，可以设计为单例或者多例的开发，推荐使用单例模式的开发（执行效率更高），默认就是单例开发模式。struts2是通过类的成员变量接收请求的参数，是基于类的开发，线程不安全，只能设计为多例的开发。
3.Struts采用值栈存储请求和响应的数据，通过OGNL存取数据，Spring MVC通过参数解析器是将request请求内容解析，并给方法形参赋值，将数据和视图封装成ModelAndView对象，最后又将ModelAndView中的模型数据通过reques域传输到页面。Jsp视图解析器默认使用jstl。
4.与spring整合不一样。Spring MVC是spring框架的一部分，不需要整合。在企业项目中，Spring MVC使用更多一些。
Spring MVC怎么样设定重定向和转发的？
（1）转发：在返回值前面加"forward:"，譬如"forward:user.do?name=method4"
（2）重定向：在返回值前面加"redirect:"，譬如"redirect:http://www.baidu.com"
Spring MVC怎么和AJAX相互调用的？
通过Jackson框架就可以把Java里面的对象直接转化成Js可以识别的Json对象。具体步骤如下 ：
（1）加入Jackson.jar
（2）在配置文件中配置json的映射
（3）在接受Ajax方法里面可以直接返回Object,List等,但方法前面要加上@ResponseBody注解。
如何解决POST请求中文乱码问题，GET的又如何处理呢？
（1）解决post请求乱码问题：
在web.xml中配置一个CharacterEncodingFilter过滤器，设置成utf-8；
<filter>
    <filter-name>CharacterEncodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>

    <init-param>
        <param-name>encoding</param-name>
        <param-value>utf-8</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>CharacterEncodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

（2）get请求中文参数出现乱码解决方法有两个：
①修改tomcat配置文件添加编码与工程编码一致，如下：
<ConnectorURIEncoding="utf-8" connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

②另外一种方法对参数进行重新编码：
String userName = new String(request.getParamter(“userName”).getBytes(“ISO8859-1”),“utf-8”)
ISO8859-1是tomcat默认编码，需要将tomcat编码后的内容按utf-8编码。
Spring MVC的异常处理？
答：可以将异常抛给Spring框架，由Spring框架来处理；我们只需要配置简单的异常处理器，在异常处理器中添视图页面即可。
如果在拦截请求中，我想拦截get方式提交的方法,怎么配置
答：可以在@RequestMapping注解里面加上method=RequestMethod.GET。
怎样在方法里面得到Request,或者Session？
答：直接在方法的形参中声明request,Spring MVC就自动把request对象传入。
如果想在拦截的方法里面得到从前台传入的参数,怎么得到？
答：直接在形参里面声明这个参数就可以,但必须名字和传过来的参数一样。
如果前台有很多个参数传入,并且这些参数都是一个对象的,那么怎么样快速得到这个对象？
答：直接在方法中声明这个对象,Spring MVC就自动会把属性赋值到这个对象里面。
Spring MVC中函数的返回值是什么？
答：返回值可以有很多类型,有String, ModelAndView。ModelAndView类把视图和数据都合并的一起的，但一般用String比较好。
Spring MVC用什么对象从后台向前台传递数据的？
答：通过ModelMap对象,可以在这个对象里面调用put方法,把对象加到里面,前台就可以通过el表达式拿到。
怎么样把ModelMap里面的数据放入Session里面？
答：可以在类上面加上@SessionAttributes注解,里面包含的字符串就是要放入session里面的key。
Spring MVC里面拦截器是怎么写的
有两种写法,一种是实现HandlerInterceptor接口，另外一种是继承适配器类，接着在接口方法当中，实现处理逻辑；然后在Spring MVC的配置文件中配置拦截器即可：
<!-- 配置Spring MVC的拦截器 -->
<mvc:interceptors>
    <!-- 配置一个拦截器的Bean就可以了 默认是对所有请求都拦截 -->
    <bean id="myInterceptor" class="com.zwp.action.MyHandlerInterceptor"></bean>
    <!-- 只针对部分请求拦截 -->
    <mvc:interceptor>
       <mvc:mapping path="/modelMap.do" />
       <bean class="com.zwp.action.MyHandlerInterceptorAdapter" />
    </mvc:interceptor>
</mvc:interceptors>

介绍一下 WebApplicationContext
WebApplicationContext 继承了ApplicationContext 并增加了一些WEB应用必备的特有功能，它不同于一般的ApplicationContext ，因为它能处理主题，并找到被关联的servlet。

推荐：博主历时三年倾注大量心血创作的《大数据平台架构与原型实现：数据中台建设实战》一书已由知名IT图书品牌电子工业出版社博文视点出版发行，真诚推荐给每一位读者！点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，扫码进入京东手机购书页面！



 

 

从MVC框架看MVC架构的设计

 

尽管MVC早已不是什么新鲜话题了，但是从近些年一些优秀MVC框架的设计上，我们还是会发现MVC在架构设计上的一些新亮点。本文将对传统MVC架构中的一些弊病进行解读，了解一些优秀MVC框架是如何化解这些问题的，揭示其中所折射出的设计思想与设计理念。

 

MVC回顾

 

作为一种经典到不能再经典的架构模式，MVC的成功有其必然的道理，这个道理不同的人会有不同的解读，笔者最认同的一种观点是：通过把职责、性质相近的成分归结在一起，不相近的进行隔离，MVC将系统分解为模型、视图、控制器三部分，每一部分都相对独立，职责单一，在实现过程中可以专注于自身的核心逻辑。MVC是对系统复杂性的一种合理的梳理与切分，它的思想实质就是“关注点分离”。至于MVC三元素的职责划分与相互关系，这里不再赘述，下图给出了非常细致的说明。

 



图1：MVC组件的功能和关系[i]

 

View与Controller的解耦：mediator+二次事件委派

 

笔者早年开发基于swing的GUI应用时,在架构MVC的实践过程中深刻体会到了view与controller之间的紧密耦合问题。在很多事件驱动的GUI框架里，如swing，用户对view的任何操作都会触发一个事件，然后在listener的响应方法里进行处理。如果让view自己注册成为事件的listener,则必须要在view中加入对controller的引用，这不是MVC希望看到的，因为这样view和controller就形成了紧密的耦合关系。若将controller注册为listener，则事件响应将由controller承担，这又会导致controller处理其不该涉及的展现逻辑,造成view和controller难以解耦的原因在于：多数的用户请求都包含一定成分的展现逻辑和一定成分的业务逻辑，两种逻辑揉合在一个请求里，在处理的时候，view与controller很难合理地分工。解决这一问题的关键是要在view与controller之间建立一种可以将展现逻辑与业务逻辑进行有效分割的机制，在这方面，PureMVC[ii]的设计非常值得参考，它通过引入mediator+二次事件委派机制很好的解决了view与controller之间的紧耦合问题。

 

Mediator是一种设计模式，这种模式在组件化的图形界面框架中似乎有着普遍的应用场景，即使是在四人帮的《设计模式》一书中，也使用了一个图形界面程序的示例来讲解mediator。mediator的设计用意在于通过一个媒介对象，完成一组对象的交互，避免对象间相互引用，产生复杂的依赖关系。mediator应用于图形界面程序时，往往作为一组关系紧密的图形组件的交互媒介，完成组件间的协调工作(比如点选某一按钮，其他组件将不可用)。在PureMVC中，mediator被广泛应用，其定位也发生了微妙的变化，它不再只是图形组件间的媒介，同时也成为了图形组件与command之间的媒介，这使得它不再是可选的，而是成为了架构中的必需设施。对应到传统MVC架构中，mediator就是view与controller之间的媒介（当然，也依然是view之间的媒介），所有从view发出的用户请求都经过了mediator再传递给controller，它的出现在一定程度上缓解了view与controller的紧密耦合问题。

 

当view、mediator和controller三者被定义出来，并进行了清晰的职责划分后，剩下的问题就是如何将它们串联起来，以完成一个用户请求了，在这方面，事件机制起到了至关重要的作用。事件机制可以让当前对象专注于处理其职责范围内的事务，而不必关心超出部分由谁来处理以及怎样处理，当前对象只需要广播一个事件，就会有对此事件感兴趣的其他对象出来接手下一步的工作，当前对象与接手对象之间不存在直接依赖，甚至感知不到彼此的存在，这是事件机制被普遍认为是一种松耦合机制的重要原因。讲到这里插一句题外话，在领域驱动设计（Domain-Driven Design）里，著名的Domain Event模式也是有赖于事件机制的这一特性被创造出来的，其用意正是为了保证领域模型的纯净，避免领域模型对repository和service的直接依赖。回到PureMVC, 我们来看在处理用户请求的过程中，事件机制是如何串联view、mediator和controller的。在PureMVC里，当一个用户请求下达时，图形组件先在自身的事件响应方法中实现与自身相关的展现逻辑，然后收集数据，将数据置入一个新的event中，将其广播出去，这是第一次事件委派。这个event会被一个mediator监听到，如果处理该请求需要其他图形组件的协助，mediator会协调它们处理应由它们承担的展现逻辑，然后mediator再次发送一个event(这次的event在PureMVC里称之为notification)，这个event会促使某个command执行，完成业务逻辑的计算，这是第二次事件委派。在两次事件委派中，第一次事件委派让当事图形组件完成“处理其职责范围内的展现逻辑”后，得以轻松“脱身”，免于被“协调其他图件处理剩余展现逻辑”和“选择并委派业务对象处理业务逻辑”所拖累。而“协调其他图形组件处理剩余展现逻辑”显然是mediator的职责，于是第一次广播的事件被委派给了mediator. mediator在完成图形组件的协调工作后，并不会插手“选择并委派业务对象处理业务逻辑”的工作，这不是它的职责，因此，第二次事件委派发生了，一个新的event由mediator广播出去，后被某个command响应到，由command完成了最后的工作——“选择并委派业务对象处理业务逻辑”。



图2：mediator+二次事件委派机制

 

总结起来，PureMVC是通过在view与controller之间引入mediator，让view与controller变成间接依赖，用户请求从view到mediator，再从mediator到controller均以事件方式委派，mediator+二次事件委派的组合可以说是一种“强力”的解耦机制，它实现了view与controller之间的完全解耦。

 

从Controller到Command，自然粒度的回归

 

目前，很多平台的主流MVC框架在设计上都引入了command模式，command模式的引入改变了传统ＭＶＣ框架的结构，受冲击最大的就是controller。在过去传统的MVC架构里，一个controller可能有多个方法，每个方法往往对应一个user action,因此，一个 controller往往对应多个user action，而在基于command的MVC架构里，一个command往往只对应一个user action。传统MVC架构里将一个user action委派到某个controller的某个方法的过程，在基于command的MVC架构里变成了将useraction与command一一绑定的过程。如果说传统controller的管理方式是在user action与model之间建立“集中式”的映射，那么基于command的管理方式就是在user action与model之间建立“点对点式”的直连映射。



图3：从基于Controller到基于Command的架构演进

 

主流MVC框架向command转型是有原因的，除了command自身的优势之外，一个非常重要的原因就是：由于缺少合理的组织依据，controller的粒度很难拿捏。controller不同于view与model，view与model都有各自天然的粒度组织依据，view的组织粒度直接承袭用户界面设计，model的组织粒度则是依据某种分析设计思想（如OOA/D）进行领域建模的结果，controller需要同时协调view与model，但是view与model的组织结构和粒度都是不对等的，这就使得controller面临一个“在多大视图范围内沟通与协调多少领域对象”的问题，由于找不出合理的组织依据，设计者在设计controller时往往感到无所适从。相比之下，command则完全没有controller的困惑，因为command有一个天然的组织依据，这就是user action。针对一个user action设计一个command，然后将两者映射在一起，是一件非常自然而简单的事情。不过，需要说明的是这并不意味着所有command的粒度是一样的，因为不同的user action所代表的业务量是不同的，因此也决定了command是有“大”有“小”的。遵循良好的设计原则，对某些较“大”的command进行分解，从中抽离出一些可复用的部分封装成一些较“小”的command是值得推荐的。很多MVC框架就定义了一些相关的接口和抽象类用于支持基于组合模式的命令拼装。

 

不管是基于controller还是基于command，MVC架构中界定的“协调view与model交互”的控制器职责是不会变的，都需要相应的组件和机制去承载与实现。在基于command的架构里，command承担了过去controller的部分职责，从某种意义上说 command是一种细粒度的controller，但是command的特性是偏“被动”的。一方面，它对于view和model的控制力比controller弱化了很多， 比如，一般情况下command是不会直接操纵view的。另一方面，它不知道自己与什么样的user action映射在了一起，也不知道自己会在何种情况下被触发执行。支撑command的运行需要额外的注册、绑定和触发机制，是这些机制加上command一起实现了controller的职责。由于现在多数基于command的MVC框架都实现并封装了这些重要的机制，所以从某种意义上说，是这些框架自身扮演了controller角色。

 

小结

 

本文主要分析了过去传统MVC架构中存在的两大弊病：view与controller的紧密耦合以及controller粒度难以把控的问题，介绍了一些MVC框架是如何应对这些问题的，这些设计方案所体现出的优秀设计思想是非常值得学习的。

 

[i] 图片来源：http://java.sun.com/blueprints/patterns/MVC-detailed.html



[ii] PureMVC是一种MVC框架，最初使用ActionScript 3实现，现在在多种语言平台上有实现版本。官方站点：http://puremvc.org/

 

更多精彩博文：

 

 

 

领域驱动设计(Domain Driven Design)参考架构详解
 

关于垂直切分Vertical Sharding的粒度
 

企业应用集成与开源ESB产品ServiceMix和Mule介绍
 

论基于数据访问的集合类（Data Access Based Collection）和领域事件(Domain Event)模式
 

关于系统异常设计的再思考
 

 

 
 

 



 

本文由玉刚说写作平台提供写作赞助
原作者：AndroFarmer
版权声明：本文版权归微信公众号玉刚说所有，未经许可，不得以任何形式转载

前言
MVC、MVP、MVVM是我们工作和面试中都比较重要的一块，但很多时候我们却有点迷惑。比如看了好多篇文章都搞不懂MVC到底是个啥本来想写个MVP写着写着就变成MVC了，到底Databing和MVVM之间有啥见不得人的关系。本篇文章主要从发展的角度来介绍，如mvp，mvvm的出现都是为了解决前者的哪些问题。如果你有同样的疑问，本篇文章可能会给你带来一点收获。但是架构和设计模式相对来说不是那么容易捉摸透的东西，很多需要经过实践才能体会，另外由于本人水平有限，如果写的不对或者不严谨的地方，请不要打我。
MVC
可能由于MVP、MVVM的兴起，MVC在android中的应用变得越来越少了，但MVC是基础，理解好MVC才能更好的理解MVP,MVVM。因为后两种都是基于MVC发展而来的。
1、MVC眼花缭乱设计图
我们从网上搜索mvc相关资料时，如果你多看几篇文章的话可能会发现，好像他们介绍的设计图都不太一样，这里罗列了大部分的设计图








2、MVC设计图解释
到底上面列出的设计图哪个才是对的。其实都是对的。为什么这么说呢，这得从mvc的发展说起。

MVC框架模式最早由Trygve Reenskaug 于1978年在Smalltalk-80系统上首次提出。经过了这么多年的发展，当然会演变出不同的版本，但核心没变依旧还是三层模型Model-View-Control。
3、MVC三层之间的关系
箭头→代表的是一种事件流向，并不一定要持有对方，比如上图中model→view的事件流向，view可以通过注册监听器的形式得到model发来的事件。在设计中model view controller之间如果要通讯，尽量设计成不直接持有，这样方便复用。也符合mvc的设计初衷

在android中三者对应的关系如下：


视图层(View)

对应于xml布局文件和java代码动态view部分
控制层(Controller)

MVC中Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作，但是因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。
模型层(Model)

针对业务模型，建立的数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作。
由于android中有个god object的存在activity，再加上android中xml布局的功能性太弱，所以activity承担了绝大部分的工作。所以在android中mvc更像是这种形式：



因为activity扮演了controller和view的工作，所以controller和view不太好彻底解耦，但是在一定程度上我们还是可以解耦的。

Talk is cheap. Show me the code. 扯了这么多，我们来看点代码。
4、MVC sample
通过代码来看下，mvc在android中的实现


结构很简单，这里介绍下其中的关键代码
public interface BaseModel {
    void onDestroy();
}

BaseModel顾名思义就是所有业务逻辑model的父类，这里的onDestroy()方法用于跟activity或者fragment生命周期同步，在destroy做一些销毁操作
public interface Callback1<T> {
    void onCallBack(T t);
}
public interface Callback2<T,P> {
    void onCallBack(T t,P p);
}

Callback是根据View或者Controller调用Model时回调的参数个数选择使用
public class SampleModel  implements BaseModel{

    public void  getUserInfo(String uid,Callback1<UserInfo> callback)
    {

        UserInfo userInfo= new HttpUtil<UserInfo>().get(uid);
        callback.onCallBack(userInfo);

    }

    @Override
    public void onDestroy() {

    }

    public class UserInfo
    {
        private int age;
        private String name;

        public int getAge() {
            return age;
        }

        public void setAge(int age) {
            this.age = age;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }
}

SampleModel是我们业务逻辑的具体实现
public class SampleActivity extends AppCompatActivity {
    private SampleModel sampleModel;
    Button button;
    EditText textView;
    TextView tvAge,tvName;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_sample);
        sampleModel=new SampleModel();
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                getUserInfo(textView.getText().toString());
            }
        });

    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        sampleModel.onDestroy();
    }

    /**
     * 获取用户信息
     * @param uid
     */
    private void getUserInfo(String uid)
    {
        sampleModel.getUserInfo(uid, new Callback1<SampleModel.UserInfo>() {
            @Override
            public void onCallBack(SampleModel.UserInfo userInfo) {
                setDataToView(userInfo);
            }
        });
    }

    /**
     * 设置用户信息到view
     */
    private void setDataToView(SampleModel.UserInfo userInfo)
    {
        tvAge.setText(userInfo.getAge());
        tvName.setText(userInfo.getName());
    }

}



前面说了Activity充当View和Controller，但是我们依然要区分到底哪一部分是View的操作，哪一部分是Controller的操作。

我们分析下事件的流向

button点击事件的触发：View→Controller

获取用户信息事件的触发：Controller→Model

绑定用户信息到View：Controller→View

至此MVC就讲完了
5、MVC总结
我们这里根据sample来总结下：

具有一定的分层，model彻底解耦，controller和view并没有解耦
层与层之间的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有
controller和view在android中无法做到彻底分离，但在代码逻辑层面一定要分清
业务逻辑被放置在model层，能够更好的复用和修改增加业务

MVP
1、MVP说明
MVP跟MVC很相像，文章开头列出了很多种MVC的设计图，所以根据MVC的发展来看，我们把MVP当成MVC来看也不为过，因为MVP也是三层，唯一的差别是Model和View之间不进行通讯，都是通过Presenter完成。

前面介绍MVC的时候提到了算是致命缺点吧，在android中由于activity（god object）的存在，Controller和View很难做到完全解耦。但在MVP中就可以很好的解决这个问题

看下MVP的设计图：



一般情况下就这两种
2、MVP Sample
依然延续MVC的例子，修改下结构通过MVP去实现，看下项目代码结构：



callback，http包下内容基本一致，主要看下不同的地方
public interface BasePresenter {
    void onDestroy();
}

BasePresenter类似于MVC中的BaseModel，主要负责业务逻辑的实现。我们这里没有把业务逻辑放在Model里去实现，当然把主要业务逻辑放在Model中去实现也是可以的。google的MVP实现方案是把业务逻辑放在presenter中，弱化Model，我们这里也是这样做的。
public interface BaseView<P extends BasePresenter> {
    void setPresenter(P presenter);
}

BaseView是所有View的父类，将android中的view抽象话出来，只有跟view相关的操作都由baseView的实现类去完成。
public class SampleContract {
    public static class Presenter implements BasePresenter
    {
        public void  getUserInfo(String uid,Callback1<SampleModel.UserInfo> callback)
        {
            SampleModel.UserInfo userInfo= new HttpUtil<SampleModel.UserInfo>().get(uid);
            callback.onCallBack(userInfo);
        }

        @Override
        public void onDestroy() {

        }
    }
    public interface View extends BaseView<Presenter>
    {
         void setDataToView(SampleModel.UserInfo userInfo);
    }
}

Contract 契约类这是Google MVP与其他实现方式的又一个不同，契约类用于定义同一个界面的view的接口和presenter的具体实现。好处是通过规范的方法命名和注释可以清晰的看到整个页面的逻辑。
public class SampleActivity extends AppCompatActivity implements SampleContract.View{
    private  SampleContract.Presenter mPresenter;
    Button button;
    EditText textView;
    TextView tvAge,tvName;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_sample);
        setPresenter(new SampleContract.Presenter());

        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                mPresenter.getUserInfo(textView.getText().toString(), new Callback1<SampleModel.UserInfo>() {
                    @Override
                    public void onCallBack(SampleModel.UserInfo userInfo) {
                        setDataToView(userInfo);
                    }
                });
            }
        });

    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mPresenter.onDestroy();
    }

    @Override
    public void setDataToView(SampleModel.UserInfo userInfo) {
        tvAge.setText(userInfo.getAge());
        tvName.setText(userInfo.getName());
    }


    @Override
    public void setPresenter(SampleContract.Presenter presenter) {
        mPresenter=presenter;
    }
}

这里的SampleActivity实现了SampleContract.View只是作为View存在的。虽然看起来，跟MVC中的实现很相似，但却有本质的区别。mPresenter为Model和View之间交互的桥梁。Presenter跟View相互持有，这里SampleActivity实现了SampleContract.View，mPresenter作为SampleActivity的成员变量，SampleActivity当然持有mPresenter，由于mPresenter是非静态的成员标量，因此默认持有SampleActivity的引用。
3、MVP总结
通过引入接口BaseView，让相应的视图组件如Activity，Fragment去实现BaseView，实现了视图层的独立，通过中间层Preseter实现了Model和View的完全解耦。MVP彻底解决了MVC中View和Controller傻傻分不清楚的问题，但是随着业务逻辑的增加，一个页面可能会非常复杂，UI的改变是非常多，会有非常多的case，这样就会造成View的接口会很庞大。
MVVM
1、MVVM说明
MVP中我们说过随着业务逻辑的增加，UI的改变多的情况下，会有非常多的跟UI相关的case，这样就会造成View的接口会很庞大。而MVVM就解决了这个问题，通过双向绑定的机制，实现数据和UI内容，只要想改其中一方，另一方都能够及时更新的一种设计理念，这样就省去了很多在View层中写很多case的情况，只需要改变数据就行。

先看下MVVM设计图：



一般情况下就这两种情况，这看起来跟MVP好像没啥差别，其实区别还是挺大的，在MVP中View和presenter要相互持有，方便调用对方，而在MVP中 View和ViewModel通过Binding进行关联，他们之前的关联处理通过DataBinding完成。
2、MVVM与DataBinding的关系
一句话表述就是，MVVM是一种思想，DataBinding是谷歌推出的方便实现MVVM的工具。在google推出DataBinding之前，因为xml layout功能较弱，想实现MVVM非常困难。而DataBinding的出现可以让我们很方便的实现MVVM。
3、DataBinding简介
DataBinding是实现视图和数据双向绑定的工具，这里简单介绍下基本用法，详细用法可以参照官方:https://developer.android.com/topic/libraries/data-binding/

启用DataBinding，只需要在gradle文件中添加如下代码：
android {    
    dataBinding{
        enabled true
    }
}

通过DataBindingUtil可以动态生成一个ViewDataBinding的子类，类名以layout文件名大写加Binding组成，如：
ActivitySampleMvvmBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_sample_mvvm);

在layout中需要我们配置，每个控件绑定的实体对象，以layout进行包裹，data中配置变量名和类型，通过@{}或@={}的方式进行引用，其中@={}的方式表示双向绑定。目前支持双向绑定的控件如下：

AbsListView android:selectedItemPosition

CalendarView android:date

CompoundButton android:checked

DatePicker android:year, android:month, android:day

NumberPicker android:value

RadioGroup android:checkedButton

RatingBar android:rating

SeekBar android:progress

TabHost android:currentTab

TextView android:text

TimePicker android:hour, android:minute

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
    <data >
        <variable
            name="user"
            type="com.androfarmer.mvvm.model.SampleModel.UserInfo">
        </variable>
    </data>
<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <TextView
        android:id="@+id/tv_name"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@={user.name}"
        />
    <TextView
        android:id="@+id/tv_age"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@={user.age+``}"
        />

</LinearLayout>
</layout>


以上为具体在xml的用法展示
public static class UserInfo  extends BaseObservable
    {
        private int age;
        private String name;

        @Bindable
        public int getAge() {
            return age;
        }

        public void setAge(int age) {
            this.age = age;
            notifyPropertyChanged(BR.age);
        }

        @Bindable
        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
            notifyPropertyChanged(BR.name);
        }
    }

为了实现双向绑定还需要对数据实体类做处理，继承BaseObservable，对读写方法做@Bindable和notifyPropertyChanged处理。还可以直接使用官方提供的泛型可观察对象 ObservableField，比如：

private ObservableField name=new ObservableField<>();
4、MVVM Sample
MVVM中跟MVP中一样，将三层划分的很清楚，Activity和xml layout充当View，ViewModel处理业务逻辑以及获取数据，弱化Model。

很多代码跟前面类似，这里只列出核心代码，ViewModel层的
public interface BaseViewModel {
    void onDestroy();
}

public abstract class AbstractViewModel<T extends ViewDataBinding> implements BaseViewModel {
    public T mViewDataBinding;
    public AbstractViewModel(T viewDataBinding)
    {
        this.mViewDataBinding=viewDataBinding;
    }

    @Override
    public void onDestroy() {
        mViewDataBinding.unbind();
    }
}

public class SampleViewModel extends AbstractViewModel<ActivitySampleMvvmBinding> {

    public SampleViewModel(ActivitySampleMvvmBinding viewDataBinding) {
        super(viewDataBinding);
    }

    public  void getUserInfo(String uid, Callback1<SampleModel.UserInfo> callback)
    {
        //从网络或缓存获取信息
        SampleModel.UserInfo userInfo=new SampleModel.UserInfo();
        userInfo.setName("tom");
        userInfo.setAge(18);
        callback.onCallBack(userInfo);
    }
}

ViewMode层主要处理业务逻辑和获取数据，mViewDataBinding是通过View层传递过来。
 private SampleViewModel mSampleViewModel;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ActivitySampleMvvmBinding binding = DataBindingUtil.setContentView(this, R.layout.activity_sample_mvvm);
        mSampleViewModel=new SampleViewModel(binding);
        setDataToView();
    }
    private void setDataToView()
    {
        mSampleViewModel.getUserInfo("uid", new Callback1<SampleModel.UserInfo>() {
            @Override
            public void onCallBack(SampleModel.UserInfo userInfo) {
                mSampleViewModel.mViewDataBinding.setUser(userInfo);
            }
        });
    }

xml layout代码在上面介绍databing的用法时已给出，通过上面代码我们就将数据UserInfo跟View进行绑定了。比如我们更新用户信息，可以直接对View上的属性进行修改：

mSampleViewModel.mViewDataBinding.tvName.setText(“rose”);

也可以通过修改UserInfo实体类的字段信息：

mSampleViewModel.mViewDataBinding.setUser(userInfo);
从此告别MVP中View层好多接口的问题，让View变得更简洁，修改任何一方，两者都会保持数据同步。
5、MVVM 总结
看起来MVVM很好的解决了MVC和MVP的不足，但是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel、LiveData、DataBinding去实现MVVM
关于MVC,MVP,MVVM如何选择的探讨
前面在介绍MVC、MVP、MVVM时并没有去详细列出他们的优缺点，主要原因有两个：

网上这方面总结的还是挺多的
其实关于架构，设计，模块化等等，它们的优缺点没有绝对的，主要看实现者如何去做

比如在mvp中我们要实现根据业务逻辑和页面逻辑做很多Present和View的具体实现，如果这些case太多，会导致代码的可读性变差。但是通过引入contract契约类，会让业务逻辑变得清晰许多。因此不管是用哪种设计模式，只要运用得当，都可以达到想要的结果。
如果非要说怎么选的话，以我浅薄的知识建议如下：

如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
对于偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。
对于工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可。
如果想通过一个项目去学习架构和设计模式，建议用MVC然后在此基础上慢慢挖掘改进。最后你可能发现，改进的最终结果可能就变成了mvp，mvvm。

PS：代码部分很多只是为了演示具体设计模式原理，部分为伪代码，还有些代码写的不是那么严谨。本篇文章参考如下：
http://www.voidcn.com/article/p-ssodjasa-brk.html

https://www.jianshu.com/p/4830912f5162



欢迎关注我的微信公众号，接收第一手技术干货

本文简单介绍 MVC 模式的相关内容。

1 what

MVC 模式（Model–view–controller）是软件工程中的一种软件架构模式，它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC 模式的目的是实现一种动态的程序设计，简化后续对程序的修改和扩展，并且使程序某一部分的重复利用成为可能。除此之外，MVC 模式通过对复杂度的简化，使程序的结构更加直观。软件系统在分离了自身的基本部分的同时，也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长进行相关的分组：

模型（Model）：程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)；
	
控制器（Controller）：负责转发请求，对请求进行处理；
	
视图（View）：界面设计人员进行图形界面设计。
MVC 模式的图形描述如下：



MVC模式中三个组件的详细介绍如下：

模型（Model）：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“Model”有对数据直接访问的权力，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，由此，View 可以了解在数据 Model 上发生的改变。（比如：观察者模式（软件设计模式））；
	
视图（View）：能够实现数据有目的的显示（理论上，这不是必需的）。在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册；
	
控制器（Controller）：起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。
从MVC模式的一般理解来看，视图层与模型层是存在直接联系的，并且模型层的变化会通过视图层反映出来，这确实是MVC模式的标准理解，不过在我目前接触到的实际应用中，更多的情况时，视图层与模型层是通过控制层联系起来的，两者之间并无直接的联系，三者之间的关系更类似下图所示：



结合MVC模式的标准解释来看，上述模式可能是MVC模式的一种变型使用，这只是个人的武断猜测，并无实据，待以后对架构模式有深入了解后，可能就会有准确答案了(^-^)。

2 优点与缺点

2.1 MVC模式的优点

2.1.1 低耦合

通过将视图层和业务层分离，允许更改视图层代码而不必重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变，只需要改动MVC的模型层（及控制器）即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

模型层是自包含的，并且与控制器和视图层相分离，所以很容易改变应用程序的数据层和业务规则。如果想把数据库从 MySQL 移植到 Oracle，或者改变基于 RDBMS 的数据源到 LDAP，只需改变模型层即可。一旦正确的实现了模型层，不管数据来自数据库或是 LDAP服务器，视图层都将会正确的显示它们。由于运用 MVC 的应用程序的三个部件是相互独立，改变其中一个部件并不会影响其它两个，所以依据这种设计思想能构造出良好的松耦合的构件。

2.1.2 重用性高

随着技术的不断进步，当前需要使用越来越多的方式来访问应用程序了。MVC模式允许使用各种不同样式的视图来访问同一个服务端的代码，这得益于多个视图（如WEB（HTTP）浏览器或者无线浏览器（WAP））能共享一个模型。

比如，用户可以通过电脑或通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式（流程）是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面（视图）使用。例如，很多数据可能用 HTML 来表示，但是也有可能用 WAP 来表示，而这些表示的变化所需要的是仅仅是改变视图层的实现方式，而控制层和模型层无需做任何改变。

由于已经将数据和业务规则从表示层分开，所以可以最大化的进行代码重用了。另外，模型层也有状态管理和数据持久性处理的功能，所以，基于会话的购物车和电子商务过程，也能被Flash网站或者无线联网的应用程序所重用。

2.1.3 生命周期成本低

MVC模式使开发和维护用户接口的技术含量降低。

2.1.4 部署快

使用MVC模式进行软件开发，使得软件开发时间得到相当大的缩减，它使后台程序员集中精力于业务逻辑，界面程序员集中精力于表现形式上。

2.1.5 可维护性高

分离视图层和业务逻辑层使得WEB应用更易于维护和修改。

2.1.6 有利软件工程化管理

由于不同的组件（层）各司其职，每一层不同的应用会具有某些相同的特征，这样就有利于通过工程化、工具化的方式管理程序代码。控制器同时还提供了一个好处，就是可以使用控制器来联接不同的模型和视图，来实现用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

2.2 MVC模式的缺点

2.2.1 没有明确的定义

完全理解MVC模式并不是很容易。使用MVC模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考软件的架构。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。

2.2.2 不适合小、中型应用程序

花费大量时间将MVC模式应用到规模并不是很大的应用程序通常会得不偿失。

2.2.3 增加系统结构和实现的复杂性

对于简单的界面来说，非要严格遵循MVC模式，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

2.2.4 视图对模型数据的低效率访问

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

说明：如果通过控制器访问模型层（而非视图层直接访问），则避免对未变化数据的不必要的频繁访问，从而解决此问题。