MVC和MVP的区别
MVP -> Model-View-Presenter ->模型,视图,提出者 ->bean,activity,fragmen
MVC -> Model-View-Controller ->模型,视图,控制者->bean,activity,onClickListener()
两个模式其实是差不多的,相同点就是增加代码量以清晰逻辑.
目的就是解耦,代码复用,代码灵活性,代码易读性.
MVP模式：
- View不直接与Model交互，而是通过与Presenter交互来与Model间接交互
- Presenter与View的交互是通过接口来进行的，更有利于添加单元测试
- 通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑
- View可以与Model直接交互
- Controller是基于行为的，并且可以被多个View共享
- 可以负责决定显示哪个View
总结就是:View 与不与Model交互 通俗的讲,就是你代码逻辑有没有写在View中的,有就是MVC,没有就是MVP
在安卓中,fragment 就有点MVP的感觉了, 而如果只用Activity,Activity即负责刷新UI,又负责处理数据.就是MVC.
MVC:
1. 用户可以向 View 发送指令（DOM 事件），再由 View 直接要求 Model 改变状态。
2. 用户也可以直接向 Controller 发送指令（改变 URL 触发 hashChange 事件），再由 Controller 发送给 View。
3. Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。所以，Backbone 索性取消了 Controller，只保留一个 Router（路由器） 。
1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
重点来了:
事实上MVC有三个问题:
1.V和M之间不匹配,用户界面和流程要考虑易用性,用户体验优化同时考虑业务流程的精确和无错.
2.C和M之间界线不清,什么样的逻辑是界面逻辑,什么样的逻辑是业务逻辑,很难定义清楚.
3.V的变化不能完全由Model控制,即observer模式不足以支持复杂的用户交互.这其实要求VC之间要有依赖.
后来的MVP与MVVM都是为了优化V,C之间的关系而提出的.
MVP认为VC之间强绑定不可避免, 但可以加强P的能力,V变成只显示,P提供数据给V,把双向依赖简化为P直接依赖于V.
由于V的数据由P提供,则MV之间的Observer关系转移到MP之间.
MVP主要解决1,3两个问题,但代价是加重了问题2.P更重,而且与Model耦合无法框架化.但实践中view很难完全被动化,它总是会随用户的事件变化,这部分成为P的负担.