MVCMVC全称Model--View--Controller，是model-view-controller的缩写，是软件设计的一种模型，采用分离业务逻辑的方法，数据、界面展示来组织代码，在改进和定制界面和用户交互的同时，无需重写业务逻辑。其中，Model层处理数据、业务逻辑等；View层处理界面的显示结果；Controller层作为桥梁，控制View层和Model层之间的通信，实现视图展示和业务逻辑层的分离。我们常常将Android中界面部分的实现理解为MVC框架的使用，将Activity理解为MVC模式中的Controller。看起来没什么特别的，但是有几个关键点需要特别注意：View将控制权交给Controller，自己不执行业务逻辑。Controller执行业务逻辑并操作Model，但不直接操作View。可以说是对View一窍不通。View和Model的同步消息是通过观察者模式进行的，同步操作就是View自己去请求Model的数据，然后更新view。MVC优缺点优点：所有业务逻辑分离到Controller中，模块化程度高。当业务逻辑发生变化时，不需要改变View和Model，只需要将Controller换成另一个Controller（SwappableController）即可。观察者模式可以同时更新多个视图。缺点：控制器测试困难。因为视图同步操作是由View自己来完成的，而View只能运行在有UI的环境中。在没有UI环境的情况下对Controller进行单元测试时，无法验证Controller业务逻辑的正确性：Controller更新Model时，无法断言View的更新操作。视图不能组件化。视图强烈依赖于特定的模型。很难将此视图提取为另一个应用程序的可重用组件。因为不同程序的领域模型不同，MVPMVP其实是MVC的进化版，更加简单。MVC中的Controller改为Presenter，View通过接口与Presenter交互，降低耦合，方便单元测试。View：负责绘制UI元素，与用户交互（Activity、View、Fragment都可以作为View层）；模型：对数据的操作、对网络的操作等，以及业务相关的逻辑处理；Presenter：作为View和Model交互的中间环节，处理与用户交互的逻辑。Presenter可以理解为一个中间层的角色，它接受Model层的数据，处理后传递给View层，还需要处理View层的用户交互等操??作。重点：View不再负责同步的逻辑，而是Presenter。Presenter中既有业务逻辑也有同步逻辑。View需要提供一个操作界面接口供Presenter调用。(重点)相比之下，在MVC中，Controller无法操作View，View也没有提供相应的接口；而在MVP中，Presenter可以操作View，View需要提供一套接口操作供Presenter调用；Model仍然通过事件广播您自己的更改，但由Presenter而不是View收听。MVP（PassiveView）的优缺点：容易测试。Presenter通过界面执行View，在对不依赖UI环境的Presenter进行单元测试时。可以mock一个View对象，这个对象只需要实现View的接口即可。然后在Presenter中注入依赖，在单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。视图可以组件化。在MVP中，View不依赖于Model。这样View就可以脱离具体的业务场景。可以说View可以完全无视业务逻辑。它只需要为上层操作提供一系列接口即可。这允许高度可重用的视图组件。缺点：Presenter除了业务逻辑，还有很多View->Model，Model->View手动同步逻辑，导致Presenter繁琐难维护。MVVMMM模式（Model--View--ViewModel模式），与MVP模式相比，MVVM模式将Presenter替换为ViewModel，其他层与MVP模式基本一致。ViewModel可以理解为View的数据模型和Presenter的结合。MVVM采用双向绑定（data-binding）：View中的变化会自动反映到ViewModel中，反之亦然。这种模式实际上意味着框架为应用开发者做了一些工作（相当于库为我们生成了ViewModel类），开发者只需要更少的代码就可以实现更复杂的交互。MVVM的调用关系MVVM的调用关系和MVP是一样的。但是，在ViewModel中会有一个叫做Binder或Data-bindingengine的东西。之前由Presenter负责的View和Model之间的所有数据同步操作都交给了Binder。只需要在View的模板语法中强制声明View上显示的内容绑定Model中的哪条数据即可。当ViewModel更新Model时，Binder会自动更新数据到View，当用户对View进行操作（比如表单输入）时，Binder会自动更新数据到Model。这种方法叫做：Two-waydata-binding，双向数据绑定。可以简单不恰当的理解为模板引擎，但是它会根据数据变化实时渲染。重点：MVVM自动化了View和Model的同步逻辑。以往由Presenter负责的View和Model的同步不再由人工操作，而是交给了框架提供的Binder。你只需要告诉Binder，View显示的数据对应于Model的哪一部分。MVVM的优点和缺点优点：提高可维护性。解决了MVP中大量手动View和Model同步的问题，提供双向绑定机制。改进了代码的可维护性。简化测试。因为同步逻辑交给了Binder，View和Model同时发生变化，所以你只需要保证Model的正确性，View就会正确。显着减少了对视图同步更新的测试。缺点：过于简单的图形界面不适用，或者大材小用。对于大型图形应用，视图状态较多，构建和维护ViewModel的成本会比较高。数据绑定的声明是用命令式的方式写在View的模板中的，调试这些内容是没有办法打断的。结语可以看到，从MVC->MVP->MVVM，就像是一个打怪升级的过程。后者解决了前者遗留的问题，将前者的不足优化为优势。同样的demo功能，代码从一开始的一堆文件优化到只需要20行代码就可以完成。MV*模式之间的区别比较明确，希望能给对这些模式认识模糊的同学带来一些参考和思路。
