设计模式---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的优点和缺点