mvvm模式和mvc的区别_一篇文章让你彻底了解 MVC、MVP 、MVVM

MVC

MVC全名是Model--View--Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。其中Model层处理数据,业务逻辑等;View层处理界面的显示结果;Controller层起到桥梁的作用,来控制View层和Model层通信以此来达到分离视图显示和业务逻辑层。

mvvm模式和mvc的区别_一篇文章让你彻底了解 MVC、MVP 、MVVM_第1张图片

我们往往把Android中界面部分的实现也理解为采用了MVC框架,常常把Activity理解为MVC模式中的Controller。

看似没有什么特别的地方,但是由几个需要特别关注的关键点:

  1. View是把控制权交移给Controller,自己不执行业务逻辑。
  2. Controller执行业务逻辑并且操作Model,但不会直接操作View,可以说它是对View无知的。
  3. View和Model的同步消息是通过观察者模式进行,而同步操作是由View自己请求Model的数据然后对视图进行更新。

MVC的优缺点

  • 优点:
  1. 把业务逻辑全部分离到Controller中,模块化程度高。当业务逻辑变更的时候,不需要变更View和Model,只需要Controller 换成另外一个Controller就行了(Swappable Controller)。
  2. 观察者模式可以做到多视图同时更新。
  • 缺点:
  1. Controller测试困难。因为视图同步操作是由View自己执行,而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候, Controller业务逻辑的正确性是无法验证的:Controller更新Model的时候,无法对View的更新操作进行断言。
  2. View无法组件化。View是强依赖特定的Model的,如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

MVP

MVP其实是MVC的一种演进版本,它更简单,将MVC中的Controller改为了Presenter,View通过接口与Presenter进行交互,降低耦合,方便进行单元测试。

  • View:负责绘制UI元素、与用户进行交互(Activity、View、Fragment都可以做为View层);
  • Model:对数据的操作、对网络等的操作,和业务相关的逻辑处理;
  • Presenter:作为View与Model交互的中间纽带,处理与用户交互的逻辑。可以把Presenter理解为一个中间层的角色,它接受Model层的数据,并且处理之后传递给View层,还需要处理View层的用户交互等操作。
mvvm模式和mvc的区别_一篇文章让你彻底了解 MVC、MVP 、MVVM_第2张图片

关键点:

  1. View不再负责同步的逻辑,而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑。
  2. View需要提供操作界面的接口给Presenter进行调用。(关键)

对比在MVC中,Controller是不能操作View的,View也没有提供相应的接口;而在MVP当中,Presenter可以操作View,View需要提供一组对界面操作的接口给Presenter进行调用;Model仍然通过事件广播自己的变更,但由Presenter监听而不是View。

MVP(Passive View)的优缺点

  • 优点:
  1. 便于测试。Presenter对View是通过接口进行,在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象,这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中,单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
  2. View可以进行组件化。在MVP当中,View不依赖Model。这样就可以让View从特定的业务场景中脱离出来,可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。
  • 缺点:
  1. Presenter中除了业务逻辑以外,还有大量的View->Model,Model->View的手动同步逻辑,造成Presenter比较笨重,维护起来会比较困难。

MVVM

MVVM模式(Model--View--ViewModel模式),和MVP模式相比,MVVM 模式用ViewModel替换了Presenter ,其他层基本上与 MVP 模式一致,ViewModel可以理解成是View的数据模型和Presenter的合体。

MVVM采用双向绑定(data-binding):View的变动,自动反映在ViewModel,反之亦然,这种模式实际上是框架替应用开发者做了一些工作(相当于ViewModel类是由库帮我们生成的),开发者只需要较少的代码就能实现比较复杂的交互。

mvvm模式和mvc的区别_一篇文章让你彻底了解 MVC、MVP 、MVVM_第3张图片

MVVM的调用关系

MVVM的调用关系和MVP一样。但是,在ViewModel当中会有一个叫Binder,或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中,指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候,Binder会自动把数据更新到View上去,当用户对View进行操作(例如表单输入),Binder也会自动把数据更新到Model上去。这种方式称为:Two-way data-binding,双向数据绑定。可以简单而不恰当地理解为一个模版引擎,但是会根据数据变更实时渲染。

关键点:

MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地进行操作,而是交由框架所提供的Binder进行负责。

只需要告诉Binder,View显示的数据对应的是Model哪一部分即可。

MVVM的优缺点

  • 优点:
  1. 提高可维护性。解决了MVP大量的手动View和Model同步的问题,提供双向绑定机制。提高了代码的可维护性。
  2. 简化测试。因为同步逻辑是交由Binder做的,View跟着Model同时变更,所以只需要保证Model的正确性,View就正确。大大减少了对View同步更新的测试。
  • 缺点:
  1. 过于简单的图形界面不适用,或说牛刀杀鸡。
  2. 对于大型的图形应用程序,视图状态较多,ViewModel的构建和维护的成本都会比较高。
  3. 数据绑定的声明是指令式地写在View的模版当中的,这些内容是没办法去打断点debug的。

结语

可以看到,从MVC->MVP->MVVM,就像一个打怪升级的过程。后者解决了前者遗留的问题,把前者的缺点优化成了优点。同样的Demo功能,代码从最开始的一堆文件,优化成了最后只需要20几行代码就完成。MV*模式之间的区分还是蛮清晰的,希望可以给对这些模式理解比较模糊的同学带来一些参考和思路。


最后,我自己是一名从事了多年开发的Java老程序员,辞职目前在做自己的Java私人定制课程,今年年初我花了一个月整理了一份最适合2019年学习的Java学习干货,可以送给每一位喜欢Java的小伙伴,想要获取的可以关注我的头条号并在后台私信我:01,即可免费获取。

你可能感兴趣的:(mvvm模式和mvc的区别)