可结合这篇博客的项目代码，阅读本博客，会容易理解很多；
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层的实现，其他的，都是只是上层的调度，不实现；
参考文章：