浅谈mvc、mvp、mvvm

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/divaid/article/details/80710026

开始前先说下使用背景的理解吧

试想一下所有的逻辑网络请求、数据处理、数据填充都在一个Activity或者Fragment中肯定会导致逻辑非常混乱，单不说后期的维护迭代更新，只是业务理解肯定也会花费很长时间，这应该就是促使设计模式出现的原因，按照设计模式编写代码时一个是代码思路更加清晰，一个是后期优化更加方便。

然后进入正题：

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的不变，即重用！

优点

1. 模型与视图完全分离，我们可以修改视图而不影响模型
2. 可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3. 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4. 如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

缺点

1. 由于对视图的渲染放在了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各层之间解除绑定，否则可能会造成内存泄漏。

参考链接：https://www.cnblogs.com/guwei4037/p/5591183.html