1.MVC
首先定义：
视图(View)
View在Android中就是Activity跟Fragment了，里边进行视图的加载，控件的显示及控件事件的绑定总之处理View控件布局相关的逻辑。
模型(Model)
处理数据相关的逻辑，接口请求或者访问数据库或访问文件获取数据，进行数据的处理，然后把数据传输回View层进行数据填充。
控制器(Controller)
主要处理View层与Model层的交互逻辑，让View专注于View的业务，Model专注于Model的业务，也就是视图模型的协调者。
由于MVC视图层与Model层仍然有逻辑业务联系所应该促使MVP的出现。
2.MVP
View层
视图层与MVC的视图层基本类似，但是只通过Presenter与Model交互不再与Model有所联系。
Model层
当数据加载完并处理完后不在直接向View层传输数据进行填充，而是通过Presenter来向View层传输数据进行填充。
Presenter层
Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，即重用！
优点
模型与视图完全分离，我们可以修改视图而不影响模型
可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
缺点
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。
3.MVVM
与MVP十分相似，只是把与用户交互的逻辑（一般是控件的一些观察者，在用户触发后Presenter直接通知Model获取数据）放到了Presenter层，View层只负责数据的填充因此VM与View的箭头应该只有VM到View（VM把Model层的处理后的数据传回View层填充）。
推荐的是MVP或者MVVM代码风格更加清晰，不过无论哪种模式应该都要记得在页面关闭后（Activity或者Fragment关闭后）如果有网络请求要终止且最好MVC、MVP、MVVM各层之间解除绑定，否则可能会造成内存泄漏。
网友评论