Android 中 MVC、MVP 和 MVVM 对比

2019-08-16 本文已影响0人因为我的心

一、前言：

MVC、MVP和MVVM是常见的三种架构设计模式，当前MVP和MVVM的使用相对比较广泛，当然MVC也并没有过时之说。

二、三种模式对比：

1. MVC

MVC (Model-View-Controller, 模型-视图-控制器)，标准的MVC是这个样子的：

mvc.png

模型层 (Model)：业务逻辑对应的数据模型，与View无关，而与业务相关（Android 中是实体模型）；
视图层 (View)：一般使用XML或者Java对界面进行描述；
控制层 (Controllor)：对应于Activity业务逻辑，数据处理和UI处理;

缺点：

Activity 中经常会出现上千行代码;
xml的view功能太过于弱化，导致actvity里面即处理业务逻辑，又处理view。
Activity并非标准的Controller，它一方面用来控制了布局，另一方面还要在Activity中写业务代码;
Activity基本上都是View和Controller的合体，既要负责视图的显示又要加入控制逻辑，承担的功能过多，代码量大也就不足为奇。

2. MVP

MVP (Model-View-Presenter) 是MVC的演化版本，几个主要部分如下：

image.png

模型层 (Model)：主要提供数据存取功能（Android 中是实体模型）；
视图层 (View)：对应于Activity和xml，负责View的绘制以及与用户交互；
展示层 (Presenter)：负责完成View于Model间的交互和业务逻辑；

解释：

各部分之间的通信，都是双向的。
View 与 Model 不发生联系，都通过 Presenter 传递。
View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

优点：

降低耦合度，实现了 Model 和 View 真正的完全分离，可以修改 View 而不影响 Modle；
模块职责划分明显，层次清晰；
隐藏数据；
Presenter 可以复用，一个 Presenter 可以用于多个 View，而不需要更改 Presenter 的逻辑；
利于测试驱动开发，以前的Android开发是难以进行单元测试的；
View 可以进行组件化，在MVP当中，View 不依赖 Model。

缺点：

把视图操作和业务逻辑分开来，但复杂的业务同时会导致presenter层太大，代码臃肿的问题。
通过UI事件的触发对数据进行处理。activity需要编写大量的事件。通过事件调用presenter的业务处理方法。UI改变后牵扯的逻辑耦合度太高。
如果 Presenter 过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密，一旦视图需要变更，那么Presenter也需要变更了。

3. MVVM

MVVM 是 Model-View-ViewModel 的简写。和 MVP 模式相比，MVVM 模式用 ViewModel 替换了 Presenter ，其他层基本上与 MVP 模式一致，ViewModel 可以理解成是 View 的数据模型和 Presenter 的合体。MVVM 就是将其中的 View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。