深入理解 MVVM 模式

种麦南山下

已于 2022-10-11 16:38:11 修改

阅读量5.2k

点赞数 7

分类专栏： vue 文章标签：设计模式前端 vue.js

于 2022-10-11 15:46:17 首次发布

本文链接：https://blog.csdn.net/conving/article/details/127264861

版权

vue 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

一个常规软件或者 APP 一般都是服务于某种商业或者非商业述求，我们平常称为“业务需求”。随着业务需求的扩张、一个软件会变得越来越庞大，越来越复杂。所以一般都会有一套完整的架构设计、研发流程以及质量管理体系来保证整个研发过程。关于“架构设计”，这是一个很大的话题，伴随着我们的业务需求，它会涉及到方方面面，我们今天来谈一谈其中的一个基础环节——MVVM模式。

一、经典的 MVC 模式

MVC 是最常见的客户端软件架构之一，它历史悠久，简单好用，易于理解，而且目前常见的 iOS 和 Android 开发，SDK 和与其搭配的 IDE 工具都是默认以 MVC 的方式来使用的。但是我个人更喜欢 MVVM 模式，也一直坚持使用 MVVM 模式来工作了很多年。

最常见的客户端架构有三种：

MVC: Model-View-Controller
MVP: Model-View-Presenter
MVVM: Model-View-ViewModel

在 MVC 里面，Model 是数据模型；View 是视图或者说就是我们的软件界面需要去展示的东西；Controller 是用来控制Model的读取、存储，以及如何在 View上展示数据，更新数据的逻辑控制器。

对应到 iOS 开发中，View 约等于 Storyboard，Controller 就是 ViewController，Model 的话是需要我们自己去创建的一些实体（Entity）Class。
对应到 Android 开发中，View 约等于 Layout 中的 xml ，Controller 就是 Activity，Model 同上。
对应到 React-Native 开发中，View 约等于 Component 中的 render 函数部分，Controller 就是整个 Component，Model 同上。

这里为什么要说 View 约等于 Storyboard 或者 Layout 呢？因为 Storyboard 和 Layout 都被设计为一种界面（View）的描述语言，它描述了整个 View 应该长成什么样子，应该具有哪些控件。程序启动时，系统会首先读取 Storyboard 或者 Layout 文件，通过渲染引擎去把这种 View 的描述语言渲染成一个真正的 View，此时此刻的 View 才是 MVC 中的那个真正的 V。网络上还有一些文章论调，说 Activity 并不能算真正的 Controller 等等，在这里我们就不纠结这些细节了。

二、VC 到 VM 的转变

我们前面有提到一个常见的 Controller（下称 VC ）中会包含 Model 的读取、存储等功能，除此之外还会有一些控件的事件绑定和响应，甚至还有网络请求等等。

一个 VC 在包含了大量的业务逻辑后，代码就会变得特别的臃肿、不易阅读和修改。于是后来就慢慢延伸出了 MVP 和 MVVM 模式。MVP 这里我们就跳过了，直接讲 MVVM 模式。MVVM 模式顾名思义是由 Model、View 和 ViewModel（下称 VM ）组成，之前的 VC 变成了 VM。怎么来理解 VM 呢？

MVVM是一种设计思想，它是Model-View-ViewModel的缩写。它也是MVC的增强版。

Model是代表数据模型，也可以在Model中定义数据修改和操作的业务逻辑。
View是代表UI组件，它负责将数据模型转化成UI展现出来。
ViewModel是一个同步View和Model的对象。

在MVVM框架下，View和Model之间并没有直接联系，而是通过ViewModel（桥梁）进行交互。
Model和ViewModel之间的交互是双向的。

ViewModel通过双向数据绑定将View和Model层连接了起来，而View和Model之间的同步工作都是完全自动的，无需人为操作。

对于一个 Model ，比如我们要存储和显示一个人的信息，这个人具有姓名、年龄、性别这三个属性。这个Model的伪代码如下：

class Person {
    String  name;
    int     age;
    int     gender;
}

Model 的数据模型，和我们的业务需求或者说业务实体（Entity）是一一映射关系。而 ViewModel 顾名思义，就是一个 Model of View，它是一个 View 信息的存储结构，ViewModel 和 View 上的信息是一一映射关系。

以一个软件的登陆场景为例子，假设这个登录界面上有如下逻辑：

用户名输入框
密码输入框
登陆按钮，点击登陆按钮按钮置灰，显示 loading 框
登陆成功，页面触发跳转
登陆失败，loading 框消失，在界面上显示错误信息
错误信息可以分为两种情况： 1、密码错误；2、没有网络

那么我们下面来定义这样一个 ViewModel：

class LoginViewModel {
    String  userId;
    String  password;
    bool    isLoading;
    bool    isShowErrorMessage;
    String  errorMessage;
}

界面初始化

由于 LoginView 和 LoginViewModel 是映射关系，也称为绑定关系，那么 LoginViewModel 是怎样的数据，View 就按照怎样的数据来进行显示。界面第一次打开时，整个 LoginViewModel 的初始值为：

{
    userId： '',
    password: '',
    isLoading: false,
    isShowErrorMessage: false,
    errorMessage: ''
}

那么此时界面为：

用户名输入框显示为空白字符串
密码输入框显示为空白字符串
loading 框因为 isLoading = false，所以不显示
错误信息框因为 isShowErrorMessage = false，所以不显示
错误信息框里面的文字为空白字符串

触发登陆

接下来，用户输入用户名和密码，点击登录按钮，在登陆事件里面触发网络通信逻辑，同时设定 isLoading = true，伪代码如下：

function onLoginButtonClick() {
    request(url, ...);
    loginViewModel.isLoading = true;
}

此时 LoginViewModel 的值为：

{
    userId： 'this is user id',
    password: 'this is password',
    isLoading: true,
    isShowErrorMessage: false,
    errorMessage: ''
}

随着 isLoading 值的变化，因为 ViewModel 和 View 存在绑定关系，那么此时界面动态变化为：

用户名输入框显示为刚刚输入的字符串
密码输入框显示为刚刚输入的字符串
因为isLoading = true，所以显示 loading 框
因为isLoading = true，登陆按钮置灰，不可点击
错误信息框因为 isShowErrorMessage = false，所以不显示
错误信息框里面的文字为空白字符串

登录失败

接下来我们假设登陆失败，服务器返回密码错误，那么此时在服务器逻辑的相应代码里面我们去设定 isLoading = false，isShowErrorMessage = true，以及对应的errorMessage，伪代码如下：

request(url, {
    success: function() {
        ...
    },

    fail: function(err) {
        if(err.code == 1000)  { // 假设1000表示密码错误
            loginViewModel.isLoading = false;
            loginViewModel.isShowErrorMessage = true;
            loginViewModel.errorMessage = '密码错误';
        }
    }
})

此时 LoginViewModel 的值为：

{
    userId： 'this is user id',
    password: 'this is password',
    isLoading: false,
    isShowErrorMessage: ture,
    errorMessage: '密码错误'
}

接下来依然是触发界面变化，根据绑定关系重新更新显示内容：

用户名输入框显示为刚刚输入的字符串
密码输入框显示为刚刚输入的字符串
因为isLoading = false，隐藏 loading 框
因为isLoading = false，登陆按钮置为正常，可以点击
因为 isShowErrorMessage = true，显示错误信息框
错误信息框里面的文字为“密码错误”

重新登录

用户修改密码后，重新点击登陆按钮：

function onLoginButtonClick() {
    loginViewModel.isLoading = true;
    loginViewModel.isShowErrorMessage: false,
    request(url, ...);
}

到这里相信大家都会知道了，错误提示框消失，显示 loading 框，登陆按钮置灰。

所以这就是 MVVM 模式的神奇之处，让你不要去关心如何去显示登录框，如何去置灰一个按钮，如何去显示错误提示框又如何去隐藏它等等。当然，这里说的“不关心”并不代表不需要知道这些，完全不处理这些逻辑，只是在架构上给你一种更清晰，更简单的原则，那就是：

“当任何外部事件发生时，永远只操作 ViewModel 中的数据”

这里外部事件主要指界面点击、文字输入、网络通信等等事件。因为绑定关系的存在，ViewModel 变成啥样，界面就会自动变成啥样。

三、单向绑定与双向绑定

随着 ViewModel 的变化，View 会自动变化，那么 View 变化后，ViewModel 会自动变化么？比如用户在“用户名输入框”输入文字后，LoginViewModel 中的 userId 会自动存储输入值么？然后用户又删掉部分输入的内容， userId 再次立即变化么？

这里就需要引入一个新的概念了：单向绑定与双向绑定。

所谓“单向绑定”就是 ViewModel 变化时，自动更新 View
所谓“双向绑定”就是在单向绑定的基础上 View 变化时，自动更新 ViewModel

我们把前面登陆按钮点击后这一过程的代码再来梳理下，单向绑定模式下的伪代码如下：

function onUserIdTextViewChanged(textView) {
    loginViewModel.userId = textView.text;
}

function onPasswordTextViewChanged(textView) {
    loginViewModel.password = textView.text;
}

function onLoginButtonClick() {
    loginViewModel.isLoading = true;
    loginViewModel.isShowErrorMessage: false,
    login(loginViewModel.userId， loginViewModel.password);
}

大家可以看到，我们需要非常明确的在 TexView 变化事件里面去重新设定 LoginViewModel 中的值，而双向绑定模式下，根据绑定关系，这一过程就隐藏性的自动完成了。既然“双向绑定”那么智能、简单，为什么还需要“单向绑定”呢？因为在真实的“业务需求”下，实际情况是非常复杂的，虽然 ViewModel 可以和 View 形成映射关系，但是它们之间的值却不一定能直接划等号。

比如在界面上要填写性别，我们通常会提供一个下拉列表框，让用户选择。这个选择框里面至少有“未知”、“男”和“女”三种字符串值，而我们的 ViewModel 一般情况下并不直接存储这些字符串。因为 ViewModel 中的数据很大一部分情况下是来自于数据库、来自于服务器，而数据库和服务器中几乎是不可能直接把性别字符串存储在数据模型中的。一般会建立一个 int 类型的字段，用 0 表示未知；用 1 表示男人；用 2 表示女人。

那么问题来了，在 ViewModel 中一个 gender 属性类型为 int，值为 0 或者 1 或者 2 时，与其绑定的 View 怎么知道该如何来显示为“未知”、“男”或者“女”呢？

所以“属性转换器”应运而生，在给 View 绑定 ViewModel 时，发现属性值不匹配，那么就需要设定一个属性转换器。反之亦然，当性别选择下拉列表框被用户改变时，用户选择了“男”，在双向绑定模式下，那么 View 依然需要在一个属性转换器的帮助下，把“男”转换为 1，然后设定到 ViewModel 中。

上面只是最简单的一种在绑定不匹配时涉及到属性转换的情况，但是真实的世界往往会更加的错综复杂，双向绑定下的属性转换器随着业务需求的迭代常常会变得越来越庞大，而且因为绑定关系触发 ViewModel 和 View 的动态变化过程是隐藏不可见的，也给调试带来了极大的麻烦。

所以后来大家在长年累月的使用过程中，发现单向绑定可能会是更合适的一种做法。

四、把数据的请求与处理放在 ViewModel 中

针对前面的登陆代码，我们再来做一次优化，得到一个更加合理的版本：

class LoginViewModel {
    String  userId;
    String  password;
    bool    isLoading;
    bool    loginStatus;
    String  errorMessage;

    Login() {
        request(url, this.userId, this.password, {
            success: function() {
                ...
            },
            failed: function() {
                this.isLoading = false;             //触发绑定关系，隐藏登陆 loading 框
                this.isShowErrorMessage = true;     //触发绑定关系，显示错误提示框
                this.errorMessage = '密码错误';      //触发绑定关系，设置错误提示文字内容
            }
        });
    }
}

可以看到，我们把整个登陆过程放在了 LoginViewModel 中，那么登陆按钮点击后这一套响应过程也相应的有所调整：

function onUserIdTextViewChanged(textView) {
    loginViewModel.userId = textView.text;
}

function onPasswordTextViewChanged(textView) {
    loginViewModel.password = textView.text;
}

function onLoginButtonClick() {
    loginViewModel.isLoading = true;            //触发绑定关系，显示登陆 loading 框
    loginViewModel.isShowErrorMessage: false;   //触发绑定关系，隐藏错误提示框
    loginViewModel.login();                     //开始登陆
}

大家看到没有，上面这段代码再也不处理任何的数据逻辑，不关心数据库、不关心网络调用，也完全不关心界面随着数据和逻辑的变化应该如何去设置控件属性状态等等。让我们再来复习一下 MVVM 的核心原则：

“当任何外部事件发生时，永远只操作 ViewModel 中的数据”

上面这段代码它不属于 Model，不属于 View，也不属于 ViewModel，那它应该写在哪里呢？

iOS 下依然写在 ViewController 中
Android 下依然写在 Activity 或者 Fragment 中
ReactNative 下依然写在 Component 中
微信小程序下依然写在 Page 中

所以 MVC 中的 C，其实一直都默默的存在着，只是变得弱化了，一定要完整的讲的话，那就是 Model-View-Controler-ViewModel 模式。只有在理想的双向绑定模式下，Controller 才会完全的消失。

五、上帝之手

讲到这里，我们已经讲解完了整个 MVVM 模式的核心原理和使用原则，不涉及任何平台、任何语言。或者说只要你遵循以上的原则，写出来的代码都是 MVVM 模式的。但是还有一个最大的疑问，我们一直没有去探讨。那就是：

ViewModel 是如何与 View 形成的绑定关系，凭什么 ViewModel 中的数据变化了，View 就会动态变化？

我们之所以要把这个问题放在最后讲是因为数据绑定和动态变化这都是由具体的 MVVM 平台或者框架来实现的，跟 MVVM 模式没有直接关系。或者说为了达成 MVVM 模式，不同的平台、不同的框架提供了不同的实现版本来完成这一目标。当然，他们也都大同小异，核心原理差不多。

先来说说第二个疑问：“为什么会动态变化”？其实这里是有一只“上帝之手”在帮你实现这个过程，当“上帝”发现某个数据变化了，然后根据“映射”关系去帮你修改那个控件的属性。但是，我们的登陆界面是否要显示 loading 框，是否要显示错误提示，这些都是我们的业务需求，“上帝”也并不知道你到底想要怎样。所以，所谓的绑定或则映射关系是需要开发者明确来告诉“上帝”的。怎么告诉“上帝”呢？这就需要你或通过配置文件或通过代码语句来设定。

我们来总结一下这两个问题的答案：