MVVM架构使用之我见

MVC

M:Model:模型层：负责业务逻辑。

V:View：视图层：负责界面呈现

C:Controller：控制层：负责Model与View交互。

简单说：MVC就是通过Controller来操作Model层的数据，并且返回给View层展示。

MVC模式缺点

Android并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始化用户界面，接受并处理来自用户的操作请求，进而做出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。

由于Android的Controller通常在Activity、Fragment中，所以Model和View层耦合严重，不易开发和维护。

MVP

M:Model:负责获取和存储数据。

V:View:负责用户事件和视图部分的展示。

P:Presenter:作为View和Model之间沟通的桥梁。

简单说：MVP就是通过Presenter从Model层检索数据后返回给View层。

MVP模式的优缺点

优点：

Presenter完全将Model和View进行了分离，主要逻辑在Presenter里实现。

MVP也有不足之处：

接口过多，一定程度影响了编码效率。

一定程度上导致Presenter的代码量过大。

MVP遵从的面向对象原则

1） 单一职责
每个模块只负责该模块的本职工作，不越界。 如View负责UI初始化与更新， Model负责数据查询与异步， 至于逻辑判断，业务实现，放心的扔给Presenter中就好了。

2） 面向接口通信
对象的持有是造成耦合的本质原因之一，因此要达到解耦的目的，替换为接口持有最是合适不过。

View和Model之间没有联系。

View和Presenter通过接口进行交互。

在Activity中Presenter和View相互注入。

MVVM

MVVM是Model-View-ViewModel的简写。它本质上就是MVC的改进版。MVVM就是将其中View的状态和行为抽象化，让我们将视图UI和业务逻辑分开。当然这些事 ViewModel已经帮我们做了，它可以取出Model的数据同时帮忙处理View中由于需要展示内容而涉及的业务逻辑

Model：应用程序中用于处理应用程序数据逻辑的部分，它主要负责网络请求，数据库处理，I/O等的操作。

View：应用程序中处理数据显示的部分。
在Android开发中，它一般对应着xml布局文件、Activity、Fragment。
这里需要补充的是View层负责处理UI相关的工作，我们只在XML、Activity和Fragment写View层的功能而不进行业务的处理，
也就是说我们不在View层写业务逻辑和业务数据相关的代码。

ViewModel ：创建关联，将Model和View绑定起来。
这样，一旦Model发生更改，ViewModel就会立即反馈给View从而自动刷新界面。
这里需要补充的是

ViewModel只负责业务逻辑，不做任何和UI相关的事情。更新UI通过数据绑定实现，尽量在ViewModel里面做

mvvm优缺点

MVVM模式和MVp模式类似，主要目的是分离视图（View）和模型（Model），有几大优点：

低耦合，视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。

可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。

独立开发，开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xml代码。

可测试，界面向来是比较难于测试的，而现在测试可以针对ViewModel来写。

MVVM的问题：
MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
第二点：对于过大的项目，数据绑定需要花费更多的内存。