设计模式 | MVC、MVP、MVVM详析

可结合这篇博客的项目代码，阅读本博客，会容易理解很多；

MVC优缺点

• 【缺点】MVC的耦合性还是相对较高，
  View可以直接访问Model，导致3者之间构成回路。
  因此，
  【MVP与MVC的主要区别】是，
  MVP中的View不能直接访问Model，
  需要通过Presenter发出请求，View与Model不直接通信。
  另外，
  耦合性高的MVC，相对于MVP、MVVM，
  可读性、健壮性、可拓展性都大打折扣，也不便于测试；
  【MVC缺点的对立面，就是MVP、MVVM的优点】
• 【优点】简单粗暴，适合简单项目

MVP优缺点

• 【缺点】对于简单的应用来说 MVP 稍显麻烦，
  各种各样的接口与概念，使得整个应用充斥着零散的接口！！！！！
  【优点】但是对于比较复杂的应用来说，MVP 模式是一种良好的架构模式，
  它能够非常好地组织应用结构，使得应用变得灵活，拥抱变化。

• 【优点】MVP能够有效地降低View复杂性，
  避免业务逻辑被塞进View中，
  使得View变成一个混乱的“大泥坑”。

• 【优点】MVP模式会解除View与Model的耦合，
  同时又带来了良好的可扩展性、可测试性，
  保证了系统的整洁性、灵活性。

MVVM优缺点

MVVM与MVP非常相似，
它们间的区别：
View和Model进行双向绑定（data-binding），
两者之间有一方发生变化则会反应到另一方上；

MVP中的View更新需要通过Presenter，
而MVVM则不而需要，
因为View与Model进行了双向绑定，
数据的修改会直接反应到View角色上，
而View的修改也会导致数据的变更。

ViewModel角色需要做的只是业务逻辑的处理，
以及修改View或者Model的状态。

【MVVM模式有点像ListView与Adapter、数据集的关系】
这个Adapter就是ViewModel角色，
它与View进行了绑定，又与数据集进行了绑定，
当数据集合发生变化时，
调用Adapter的notifyDataSetChanged之后View就直接更新，
它们之间没有直接的耦合，使得ListView变得更为灵活。

• 【优点】
  1 .【解耦VM层】；
  2 .【对控制器瘦身】
  MVVM可以看成是MVC的进化版，
  它可以把Activity中的大量VC逻辑【UI、控制调度、业务逻辑】封装到ViewModel层中，
  使得Activity代码架构性能提升不少；
  3 .【数据双向绑定】
  当Model变化时，View-Model会自动更新，View也会自动变化。
  很好做到数据的一致性，MV联动比MVP快捷、灵活；

• 【缺点】
  1 .【ViewModel长期持有数据源时，需注意内存泄漏】
  一个大的模块中，ViewModel也会很大，
  虽然使用方便了也很容易保证了数据的一致性，
  但是当长期持有数据源，不释放内存，就造成了花费更多的内存，
  静态变量长期维持到大数据对象的引用，阻止垃圾回收，容易产生内存泄漏。
  2 .【ViewModel的灵活性、可拓展性等问题】
  业务逻辑大部分只能让ViewModel承担，
  项目一大，可读性、可测试性等就会降低；
  3 .【测试时部分问题难度增加】
  数据绑定使得部分bug调试难度增加。
  当界面异常时，
  bug可能出在View代码中，也可能出在 Model 的代码。

MVC实例分析

• M可以由数据Bean类（结合数据文件）实现；
  C即控制/调度逻辑、业务逻辑【业务功能实现】，由Activity实现；
  V则xml布局文件与UI逻辑【UI逻辑由Activity实现】；
  
  
  
• V与C的逻辑同在Activity，会相互耦合。【VC，CV】；
  
  Activity可以直接访问M层（数据类、数据操作），
  而CV两层都在Activity中，
  即CV又分别会跟M耦合【CM，VM】
  
  所以MVC三层相互耦合，耦合性很高；

• 【CV，VM】
  在Activity中，
  可以向View发送指令，即调用UI逻辑方法【CV】，
  再由View直接要求Model改变状态，即UI逻辑调度数据操作逻辑，或使得M层变化【VM】。
• Controller直接调用UI逻辑处理UI（View）【CV】。
• Controller直接调用数据操作逻辑，或使得M层变化【CM】。
• Controller起到事件路由的作用，
  同时业务逻辑都部署在Controller（Activity）中。

MVP实例分析

• presenter——交互中间人
  Presenter主要作为沟通View和Model的桥梁，
  它从Model层检索数据后，返回给View层，
  使得View和Model之间没有耦合，
  也将业务逻辑从View角色上抽离出来。
• View——用户界面
  View通常是指Activity、Fragment或者某个View控件，
  它含有一个Presenter成员变量。
  通常View需要实现一个逻辑接口，
  将View上的操作通过会转交给Presenter进行实现，
  最后，
  Presenter调用View逻辑接口将结果返回给View元素。
• Model——数据的存取
  对于一个结构化的App来说，
  Model角色主要是提供数据的存取功能。
  Presenter需要通过Model层存储、获取数据，
  Model就像一个数据仓库。
  更直白地说，
  Model是封装了数据库DAO或者网络获取数据的角色，
  或者两种数据获取方式的集合。

简单说，

• M可以由数据Bean类（结合数据文件）等实现；
  V则xml布局文件与UI逻辑，
  【UI逻辑分UI逻辑接口，UI具体逻辑，
  UI逻辑接口是定义接口实现，
  UI具体逻辑由Activity（Fragment）实现UI逻辑接口具体实现】；
  P即控制/调度逻辑、业务逻辑【业务功能实现】，
  由业务逻辑接口、业务逻辑接口实现类实现；
  
  元素小结：
  数据封装类，
  【一套业务中，下面四个元素是必须的，
  UI逻辑实现类 use 业务逻辑实现类，
  业务逻辑实现类 依赖 UI逻辑接口实例，
  类文件名、文件中逻辑，相互对应，形成一套业务！】
  UI逻辑接口，UI逻辑实现类（Activity/Fragment），
  业务逻辑实现接口，业务逻辑实现类

MVP成分解析

• 【V】UI逻辑接口抽象UI实现的逻辑；

• 【V】UI逻辑实现类（Activity/Fragment）
  实现UI逻辑接口方法，具体实现UI逻辑【更新UI、启动UI动画等】；
  
  【VP】
  准备一个业务对应的Presenter成员变量，
  用于在对应时机调度Presenter的业务方法，
  也调度对应的Presenter的绑定方法，
  让Presenter与自身绑定；

• 【P】业务逻辑实现接口抽象业务逻辑方法，

• 【P】业务逻辑实现类实现业务逻辑实现接口的逻辑方法；
  
  【PV】
  准备一个UI逻辑接口成员变量 还有 一个绑定方法，
  用于 绑定 UI逻辑接口实例，
  UI逻辑接口实例 可以 用来调用 UI逻辑实现类中的 具体实现的 UI方法，
  调用的时候可以把数据操作获得的数据也传过去View层；
  
  【PV、PM】
  业务逻辑实现类中 实现的一系列 业务方法，
  每一个 业务方法其实就是对某种场景要实现的业务逻辑的封装，
  也就是业务方法中，封装了一系列逻辑，
  也封装了一系列数据操作的方法， 和UI逻辑方法；【PV、PM】

注意！！

一个UI逻辑实现类（Activity/Fragment）可以实现多个 UI逻辑接口，
绑定多个业务逻辑实现类，
以便调用多种业务逻辑，
实现多套业务；
另外，
多个UI逻辑接口之间，
多个业务逻辑接口之间，
重复的部分可以进一步进行抽象；（可参考文首博客）

MVP规范亮点细品

• 【基于每秒的回调机制】
  UI逻辑在UI逻辑实现类（Activity/Fragment）中具体实现，
  在业务逻辑实现类中被调用；
  业务逻辑方法在业务逻辑实现类中具体实现，
  在UI逻辑实现类（Activity/Fragment）中被调用；
  
  
• 【MV解耦！！】
  按照MVP套路规范，
  View层，也就是UI逻辑实现类（Activity/Fragment）要访问数据的时候，
  一般都不是直接在自己类中具体实现数据操作逻辑的，
  而是通过调用业务逻辑实现类【P】的业务方法，
  间接调用到业务方法中的数据操作逻辑；
  
  即，MV解耦，
  V层制作V层的实现，其他的，都是只是上层的调度，不实现；

---

参考文章：

• MVVM的优点和缺点