MVC 、MVP 和 MVVM

Posted by liveipool on February 23, 2017

MVC 、MVP 和 MVVM

MVC

  • MVC是三个单词的首字母缩写,它们是Model(模型)View(视图)Controller(控制)
  • 它是一种框架模式,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件(Controller)里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。
  • 使用MVC的目的是将模型和视图实现代码分离,从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步,一旦M改变,V应该同步更新
  • 最上面的一层,是直接面向最终用户的”视图层”(View)。它是提供给用户的操作界面,是程序的外壳。
  • 最底下的一层,是核心的”数据层”(Model),也就是程序需要操作的数据或信息。
  • 中间的一层,就是”控制层”(Controller),它负责根据用户从”视图层”输入的指令,选取”数据层”中的数据,然后对其进行相应的操作,产生最终结果。
  • 这三层是紧密联系在一起的,但又是互相独立的,每一层内部的变化不影响其他层。每一层都对外提供接口(Interface),供上面一层调用。这样一来,软件就可以实现模块化,修改外观或者变更数据都不用修改其他层,大大方便了维护和升级。
    MVC.png

MVC的优缺点

  • 优点:
  • 耦合性低
  • 重用性高:多个视图能共享同一个模型等。(也不够高,这也是后来会出现MVP和MVVM的原因之一)
  • 部署快:使用MVC框架模式可以缩短开发时间。
  • 可维护性高
  • 有利于软件工程化管理:软件工程化是指用系统化、 规范化、 数量化等工程原则和方法去进行软件的开发和维护
  • 缺点:
  • 不适合中小型规模的应用程序
  • 增加系统结构和实现的复杂性:对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。
  • 视图与控制器间的连接过于紧密:视图与控制器是相互分离,但却是联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
  • 视图会包含一些业务逻辑:因为在MVC里,View是可以直接访问Model的从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。 所以在MVC模型里,Model不依赖于View,但是View是依赖于Model的。不仅如此,因为有一些业务逻辑在View里实现了,导致要更改View也是比较困难的,至少那些业务逻辑是无法重用的。

框架模式和设计模式的区别

  • 有很多程序员往往把框架模式和设计模式混淆,认为MVC是一种设计模式。实际上它是一种框架模式,它们完全是不同的概念。
  • 注意框架和框架模式又有不同。如Spring的就是基于MVC框架模式的一种框架,Vue是基于MVVM框架模式的一个框架。
  • 框架模式有:MVC 、MVVM、MVP等
  • 设计模式有:工厂模式、适配器模式、策略模式等

设计模式,架构,框架和类库的区别

(转载过来,防止以后原文不见了)原文:设计模式,架构,框架和类库的区别
我类比的例子是盖房子,我先从设计模式说起。人类从住山洞到现在的住高楼大厦中间的居住形态经历了无数次的演变,不同的人用自己的智慧诠释了对居住环境的理解,并且由于有了文字这些经验都被记录下来了。现在打个比方,如果让学计算机的你在一个深山老林里,什么都不给你,你能盖出什么样的房子呢?我猜肯定是什么也盖不出来,只能去睡山洞了,为什么呢,因为你什么都没有,没有材料 ,没有工具,甚至没有盖房子的知识,这时有另一个答案,如果你足够长寿,你也可以自己把所有盖房子要用到的材料,工具,知识都发明出来 。这里提到的材料,工具,知识,都是前人不断积累而成的,我想这些当中的每一项,每一项个具体的点都是为了解决实际盖房子过程 中遇到的各种问题而产生的。

我认为这个就可以解释编程当中的设计模式,当然要注意到我打的比方当中与编程的背景是不同的,说不通的地方肯定是有的,但不要太钻牛角尖。设计模式,就是一种设计思想,是解决问题的思路,当你以后遇到其他类似问题(想想,当你盖好第一个房子以后,再让你盖一个,你是不是就有思路了?),你可以采用类似的思路(设计模式)来解决。

再说说什么是架构,盖房子的时候,你在盖之前,先要想想怎么盖,盖成什么样子的,还有会影响你盖房子的一些因素,例如四季的温度,房子的朝向,房子的位置等等,总之在综合 考虑各种因素的影响下,最终你知道这个房子应该大概是个什么样子了,给你纸笔你都可以把房子的大概样子给画出来。那么恭喜你,你的房子的架构确定了。在开发一个项目的时候,当你综合考虑各种因素后,确定的项目的样子就是架构

那么什么是框架呢,还是说盖房子, 会盖房子的人很多,但有的人特别会盖某种房子,例如2层小楼,于是他就创业了,专门为想盖2层小楼的人提供方法,各种规范化的材料和工具 ,这个人在创业的过程中,又不断的发展自己的理论,于是他又能盖高楼和欧式建筑,甚至金字塔了,但你要想建那种建筑,必须得用他提供的方法,按照他的建筑规范,用它的材料和工具,才能建的成,如果你用他的方法,别人的材料和工具,那这个房子就有可能坏掉。这里,可以说 ,这个人他提供给你的就是一种盖房子的框架。同理,如果你要开发个程序,在一个优秀开发框架的帮助下,你就可以少走很多弯路。

框架的类比还没完,假如你什么框架都不用,你自己会盖房子的基本原理,你也能把房子盖起来,但就是没别人盖的好看,盖的快,门也是手工 制的,很粗糙,而且盖的时候还经常遇到不明白的地方,然后你到处找资料,最后弄懂了,问题才得以解决。那么回过头来想想,为什么你用框 架的时候有些问题就遇不到,那是因为框架再代替你做很多事情,框架解决了怎样盖房子的问题,而只让你去考虑盖个什么样的房子的问题。( 这就是开发框架追求的,集中考虑业务逻辑的类比)。

框架和设计模式有什么关系呢,正像前面所说的,框架是解决怎么样盖房子,而你仍然要解决盖个什么样的房子,这实际上是将一件事分成的两个阶段,第一个阶段是聪明的人从盖房子的过程中总结抽象出来的一种普遍使用 的理论,从而提高了盖房子的效率,降低了盖房子的难度。而解决如何盖房子的问题的时候,这就像是在解决一类问题,而具体盖房子就像是一个实例,实际上他们在形成过程中有类似的地方,都会遇到问题,而遇到问题时就都会运用一些设计模式加以解决。只有知道怎么盖房子,考虑盖什么样的房子才是合理的做法,同样,只有熟悉各种设计模式,才能研究说更多更好的盖房子的方法。这里面有个知识演变的过程。 正像你开发一个项目时,你先要知道怎么开发项目,怎么用开发框架来开发项目(不要问为什么用开发框架了,前面的盖房子的论述中有提到) ,而这个开发框架在形成过程中必然要用到各种设计模式。但在开发具体的项目的时候,设计模式还是会被用到的,这一方面是框架的原因,另 一方面是设计模式本身的性质决定的。所以设计模式应该是贯穿开发过程始终的,编码级的思想理论。这时再谈到框架,我想框架就是编码级的 方法论,而架构就是项目级的设计理论。

最后再谈谈类库和框架的关系,大家都知道面向对象的开发框架中都有各种类库,很多都功能 类似,又有不同的差别,这个可以打个和盖房子有点关系的理论,比如门,有许多种,每种都是用不同的方式批量生产出来的。为了提高盖房子 的效率,降低难度,我会从各种门中找出符合我要求的门,或者说生产这种门的方法,将这种方法纳入我提出的这种盖房子理论的体系中来,这种生产门的方法,就是一种类库,生产其他门的方法是其他的类库,另外还有生产窗的,灯的,锁的等等,等等。从中不难看出类库和框架的关系,可以说类库的结合体就组成了一种框架。但之所以说是框架,而不是类库的结合体,就是因为他们是有机的结合体,这个有机说的是一种机制,一种思想,是框架的核心。类库和设计模式的关系就很简单了,类库的实现过程中是直接应用了各种设计模式的。因此按照从小到大的顺序我们排列一下标题提到的这四个名词,就是:设计模式,类库,框架,架构。如果从作用来讲,是个三角形或者V 字形的顺序,文字描述为,类库会用到设计模式,框架会用到类库,架构会用到框架,架构定了,开始做项目的时候还会编写类,还会用到设计 模式最后再延伸一点,我认为这四个词是站在编码角度在论述的,另一个角度就是项目的角度,同样也有几个词,从小到大依次是,方 法,过程,工程,管理。简单说一下这四个词背后所代表的概念。方法,例如TDD,BDD,MDD,DDD,OOP/OOA,AOP等等过程,例 如Scrum,敏捷开发,极限开发,瀑布工程,例如需求,设计,编码,测试,维护管理,例如生命周期,里程碑,跟踪,报表,成本核算 ,绩效考核等等

MVP

MVP.png
MVP 是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。
改进的思想很简单,就是要切断View和Model的联系。

作为一种新的模式,MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVC里,View是可以直接访问Model的从而,View里会包含Model信息,不可避免的还要包括一些业务逻辑。 在MVC模型里,更关注的Model的不变,而同时有多个对Model的不同显示,即View。所以,在MVC模型里,Model不依赖于View,但是View是依赖于Model的。不仅如此,因为有一些业务逻辑在View里实现了,导致要更改View也是比较困难的,至少那些业务逻辑是无法重用的。
虽然 MVC 中的 View 的确“可以”访问 Model,但是我们不建议在 View 中依赖 Model,而是要求尽可能把所有业务逻辑都放在 Controller 中处理,而 View 只和 Controller 交互。

MVP的优缺点

  • 优点:
  • 模型与视图完全分离,我们可以修改视图而不影响模型
  • 可以更高效地使用模型,因为所有的交互都发生在一个地方——Presenter内部
  • 我们可以将一个Presenter用于多个视图,而不需要改变Presenter的逻辑。这个特性非常的有用,因为视图的变化总是比模型的变化频繁。
  • 如果我们把逻辑放在Presenter中,那么我们就可以脱离用户接口来测试这些逻辑(单元测试)
  • 缺点:
  • 由于对视图的渲染放在了Presenter中,所以视图和Presenter的交互会过于频繁。
  • 而如果Presenter过多地渲染了视图,往往会使得它与特定的视图的联系过于紧密。

MVVM

  • MVVM(Model-View-ViewModel)框架的由来便是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去,以应对客户日益复杂的需求变化。
  • WPF(Windows Presentation Foundation)是微软推出的基于Windows Vista的用户界面框架,属于.NET Framework 3.0的一部分。它提供了统一的编程模型、语言和框架,真正做到了分离界面设计人员与开发人员的工作;同时它提供了全新的多媒体交互用户图形界面。
    MVVM.png

MVVM 的优点

  • 低耦合。视图(View)可以独立于Model变化和修改,一个ViewModel可以绑定到不同的”View”上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
  • 可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。
  • 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计。
  • 可测试。界面素来是比较难于测试的,而现在测试可以针对ViewModel来写。

MVVM和MVP比较像,但还是有些区别。
ViewModel大致上就是MVP的Presenter和MVC的Cotroller了,而View和ViewModel间没有了MVP的界面接口,而是直接交互,用数据”绑定“的形式让数据更新的事件不需要开发人员手动地去编写特殊用力,而是自动地双向同步。数据绑定可以认为是Observer模式或者是Publish/Subscribe模式,原理都是为了用一种更集中的方式实现频繁需要被实现的数据更新问题。
比起MVP,MVVM不仅简化了业务与界面的依赖关系,还优化了数据频繁更新的解决方案,甚至可以说提供了一种有效的解决模式。

MVC , MVP 和 MVVM的区别

阮一峰老师总结得清晰明了:MVC,MVP 和 MVVM 的图示

赞赏码.jpeg