Android设计模式理解（mvc mvp mvvm）

android设计模式理解(m mvp mvvm)。

mvc：

modle-view-controller 把一个个应用的输入，处理，输出流程按照 modle，view，controller进行分离

modle:模型层 就是应用程序中的二进制数据

view:视图层 就是应用程序的界面 android中的界面采用xml文件保存的，界面开发变得很方便

controller：控制层 控制视图模型的数据显示

存在问题：controller (例如activity)中存在两部分内容：

业务相关+界面相关

这样就造成v层的代码相对较少，c中代码相对较多

解决方案:

1.将activity中的业务相关内容拆分：mvp

2.将activity中界面相关的内容拆分：mvvm

mvp:

model-view-presenter

拆分业务相关部分 要目的是划分模块职责,降低模块耦合,易测试,提高代码复用

presenter: 作为model和view的中间协调部分,负责两者之间的业务逻辑处理

view会抽象出来一系列操作ui的接口(model层也可以),presenter拿到的都是其他两个层级的接口来做业务逻辑的处理.这样不仅可以使view和model之间的耦合度降低,还可以更易得进行单元测试.

mvp的优缺点

优点:降低耦合，层级职责更明显，易于单元测试

缺点:造成类数量爆炸，代码复杂度和学习成本高，在某些场景下presenter的复用会产生接口冗余

mvvm:

拆分界面相关部分

一种在windows上已经使用多年的开发模式-model-view-viewmodel (mvvm)。

将view和一个对象的对field绑定。当field更新的时候，framework将收到通知，同时view也会自动更新。

mvvm模式包含了三个部分：

model – 代表你的基本业务逻辑

view – 显示内容

viewmodel – 将前面两者联系在一起的对象

一个viewmodel接口提供了两个东西：动作和数据。动作改变model的下层(click listener，监听文字改变的listener等等)，而数据则是model的内容。

比如，为一个拍卖页面服务的viewmodel可能被作为数据呈现：item里的一张图片，标题，描述，价格。也可能作为动作呈现：投标，购买或者联系卖家。

在传统的安卓架构中，controller负责推送数据给view。在activity中findview，然后在它上面设置内容。在mvvm中，viewmodel在改变内容之后通知binding framework内容发生了改变。然后framework自动更新和那些内容绑定的view。这两个组建只是通过viewmodel松耦合在一起。

这种设计模式之所以牛逼，除了明显智能化了的view之外，还方便了测试。

比如，在一个测试用例中，我们不将vm和一个真实的view绑定，而是直接创建一个vm，给它一些数据，然后在上面调用操作，以确保数据的变化是正确的。比如刚刚的拍卖案例中，你可以创建一个带虚拟(模拟的)api服务的vm

，让它载入任意的item然后在上面调用拍卖的行为，以确认结果数据是正确的。所有这些工作都不必和一个具体的view交互。

而在测试view的时候，我们可以创建一系列带有预先设置好数据(比如依赖于网络调用的或者内容的)的模拟model，然后观察在不同的数据集合面前view是如何表现的。

但是由于框架的侵入性太强，导致一直没有流行起来。