MVP-MVVM

最新推荐文章于 2018-08-15 11:26:27 发布

LeoHoFly

最新推荐文章于 2018-08-15 11:26:27 发布

阅读量335

点赞数

分类专栏：原创文章标签： mvp mvvm

本文链接：https://blog.csdn.net/jaden_hool/article/details/78974676

版权

34 篇文章 2 订阅

订阅专栏

Model提供用户界面需要显示的数据，包括从服务器获取数据、从本地缓存获取数据等数据操作。

View层应该尽量的精简，负责显示数据和用户交互。MVP下Activity和Fragment体现在了这一层，Activity一般也就做加载UI视图、设置事件监听再交由Presenter处理的一些工作，所以也就需要持有相应Presenter的引用。

Presenter层处理程序的业务逻辑，收到View层UI上的反馈、系统反馈等指令后分发处理逻辑交由业务层做具体的业务操作，然后将得到的数据给View层展示。

解耦，实现了Model和View真正的完全分离。
模块职责划分明显，层次清晰，方便调试，不容易出bug. 而且各模块之间只暴露接口，可供多名开发者同步开发。
Presenter可以复用，一个Presenter可以用于多个View.
易于进行单元测试，Android中的单元测试一直以来都是一个难题，其中一个原因就是View层的测试比较难写，引入MVP后，由于Presenter只持有View的接口，那就可以通过Mock View来测试业务逻辑，不用依赖真正的Android控件。

Android中的View层不够纯粹，Activity和Fragment和Android系统API紧密相关，例如生命周期回调，本不应该属于View层，而应该由Presenter层处理，使用MVP就需要手动将生命周期回调处理交给Presenter层代理。
Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。
由于对View的渲染放在了Presenter中，所以View和Presenter的交互会过于频繁。
如果Presenter过多地渲染了View，往往会使得它与特定的View的联系过于紧密。一旦View需要变更，那么Presenter也需要变更了。
额外的代码复杂度及学习成本。

Android中实现MVVM, 需要依赖官方提供的DataBinding库。DataBinding提供了View和数据的双向绑定，正向：View监听数据的改变自我渲染。反向：View将用户操作之后的数据反向注入给数据层。

和MVP一致

监听数据的变化自我渲染，并且将与用户交互的事件反馈给ViewModel层处理。

用可监听的对象对View层所需的数据进行包装，并且处理View层传递的用户交互事件，ViewModel并不持有View, 而是通过注解接收View层的事件。

MVVM 使得 View 和逻辑层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了 Activity 的压力。
逻辑层完全没有持有 View，后台异步任务也就不需要持有 View, 避免出现内存泄漏。
单元测试更加简单，ViewModel层完全没有持有View, 所以不需要mock view, 只需要测试当数据发生改变时，Observable variables的表现即可。

数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
数据双向绑定不利于代码重用。客户端开发最常用的重用是View，但是数据双向绑定技术，让你在一个View都绑定了一个model，不同模块的model都不同。那就不能简单重用View了。
更加大的学习成本