mvc, mvp, mvvm 概念

MVC

image.png

M-V之间是Observer模式,即V直接依赖M,M间接依赖V.M,C之间是C直接依赖M.这两点是MVC中最广泛认可,同时也是MVC成为一个解决方案模式的关键:视图和逻辑分离.
理想的MVC模式中V-C之间没有直接依赖(没有单向依赖),但现实中做不到.Native应用要一般由view分发事件给controller,controller要决定那些view用户可见.
Web应用中情况好一点.用户可以直接通过url直接访问controller,不需要view知道controller,但是controller还负责路由view.前端复杂化后,页面上与controller交互更频繁,controller也很难只通过url来实现了。

事实上MVC有三个问题:

  1. V和M之间不匹配,用户界面和流程要考虑易用性,用户体验优化同时考虑业务流程的精确和无错.
  2. C和M之间界线不清,什么样的逻辑是界面逻辑,什么样的逻辑是业务逻辑,很难定义清楚.
  3. V的变化不能完全由Model控制,即observer模式不足以支持复杂的用户交互.这其实要求VC之间要有依赖.
    后来的MVP与MVVM都是为了优化V,C之间的关系而提出的

MVP



MVP认为VC之间强绑定不可避免, 但可以加强P的能力,V变成只显示,P提供数据给V,把双向依赖简化为P直接依赖于V;
由于V的数据由P提供,则MV之间的Observer关系转移到MP之间;
MVP主要解决1,3两个问题,但代价是加重了问题2,P更重,而且与Model耦合无法框架化.但实践中view很难完全被动化,它总是会随用户的事件变化,这部分成为P的负担.

在android实践中,View一般是activity/fragment,主要问题是View和Presenter的配合生硬,像唱双簧一样需要两者一起配套改动

MVVM

image.png

而MVVM则是另一个方面来解决问题,MVVM认为view应该是事件驱动,模型变化只是一种事件,C应该只处理view与模型不配合的问题,而问题3可以通过分离用户交互与界面构造,C退化为一个View的模型VM,它与view之间由框架提供事件-数据的绑定;
MVVM与MVP相比主要彻底解决了问题1,重新定义了问题2,在MVVM中VM的功能比较明确,把M翻译成View需要的数据;
VM有一定视图的属性,view与VM有对应关系,也就解决一部分问题3,但是由于各角色职责已经定义,需要引入第四个组件来解决这个问题.

在android实践中,MV双向绑定有DataBinding库支持,ViewModel 字段的可以是DataBinding提供的Obserable<T>,以及google io 2007新推出的LiveData;

Demo:TBD

比较

我们可以打个分,直接依赖计为1,间接依赖计为0.5
全部互相依赖是6
理想MVC,MV=1.5,MC=1共2.5
现实MVC根据VC之间的依赖情况可能是0.5到2,实际是3到4.5
MVP,MP=1.5,VP=1,MV=0共2.5与理想情况一致.
MVVM,MVM=1.5,VM+V=0.5或1,共2到2.5,即不高于理想MVC

推荐阅读更多精彩内容