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