从MVC到MVVM：从过程式走向声明式

以前学习MVVM模式时写了一篇《MVC、MVP和MVVM》。近来重读，有了一些新想法。从MVC模式到MVVM模式的变化，体现出在技术推动下，界面构造方法从传统的过程式向声明式演进。从“在坐标(x,y)到(a,b)之间绘制一个红色矩形”到“坐标(x,y)到(a,b)之间存在一个红色矩形”。

我们先简单了解一下从MVC到MVVM的演进过程。

图1  从MVC到MVVM的演进过程

从上图可以看出，业务发展引发界面复杂度超出过程式构造方法适用范围，为演进提供了驱动力和必要性。而数据绑定等自动化技术的突破为演进提供了路径和可行性。在两种要素的推动下，MVC最终演进为MVVM。

1. MVC：解耦业务逻辑/过程式渲染

在早期的应用中，业务逻辑、界面渲染和用户交互代码常常混合在一起，导致软件难以维护和进化。MVC通过引入一个中间层（Controller）对业务逻辑解耦，解决了这个问题。MVC模型包含3个概念：执行业务逻辑的Model、负责展示的View、处理用户输入，协调Model和View的Controller。三者的静态结构和动态结构如下：

图2  MVC模型静态结构

图3  MVC模型动态结构

代码1  MVC模型代码示例

class Controller {
  Model model;
  View view;

  void onClick() {  
    UserInput userInput = view.getUserInput();
    model.operate(userInput);
    Data newData = model.getData();
    view.getTextView().setText(newData.getText());
  }  
}

MVC完成了业务逻辑的解耦，但界面渲染和用户交互的解耦并不彻底。Controller既处理用户输入，又负责更新View。随着业务逻辑逐渐复杂，Controller代码变得臃肿，难以维护。Controller是一个重要的协调者，但由于存在对View的依赖，Controller难以进行测试。从渲染的角度来看，渲染的过程是被动和过程式的。每次更新界面，Controller向View发出绘制指令，View根据指令绘制界面。这个过程中需要编写大量的代码绘制界面。

2. MVP：解耦渲染指令/半声明式渲染

MVP进一步对界面渲染指令进行解耦，同样的方法，引入中间层。MVP包含3个主要概念，Model、View和Presenter。看起来只是给Controller换了个名字，实际上MVP完成了渲染指令的解耦。View不再暴露底层渲染指令，而是提供高层级的更新界面方法。同时为了便于测试，MVP将View提供的高层级的更新界面方法封装成接口，构成了MVP中的一个隐含概念：ViewInterface。Presenter不再依赖View，而是采用面向接口编程原则，让Presenter和View共同依赖于ViewInterface。

图4  MVP模型静态结构

图5  MVP模型动态结构

代码2  MVP模型代码示例

class Presenter {
    Model model;
    // Presenter不再直接依赖于View，而是依赖于ViewInterface。
    ViewInterface viewInterface;  

    void onClick() {  
      UserInput userInput = view.getUserInput();
      model.operate(userInput);
      Data newData = model.getData();
      // Presenter不再直接执行底层绘制指令，而是调用高层界面更新接口。
      viewInterface.update(newData);
    }  
  }  

  class View {
    View() {
      addClickListener(event -> presenter.onClick())
    }
  }

在MVC中，驱动者Controller直接调用底层渲染指令。而在MVP中，驱动者Presenter调用高层界面更新方法，由View决定具体执行的底层渲染指令。MVP是由过程式向声明式转变的中间状态。

3. MVVM：自动渲染/声明式渲染

MVP将渲染指令封装在View中，将驱动者和渲染指令解耦。但这仍然是不彻底的，仍然需要在View中编写大量的渲染代码。MVVM则更进一步，利用数据绑定机制，实现了声明式界面构建。驱动者ViewModel只需要声明预期的界面效果，数据绑定机制完成由效果到渲染指令的转换，实现自动渲染。在MVVM中，已经不再需要手动编写渲染代码。

图6  MVVM模型静态结构

图7  MVVM模型动态结构

代码3  MVVM模型代码示例

class ViewModel {
    Model model;
    // 通过数据绑定直接获取用户输入。
    @DataBind String userInput;
    @ViewBind String outputText;

    void onClick() {  
      model.operate(userInput);
      Data newData = model.getData();
      // 通过数据绑定自动更新界面。
      outputText = newData.getText();
    }  
  }  

  class View {
    View() {
      addClickListener(event -> viewModel.onClick())
    }
  }

4. 从过程式走向声明式

从MVC到MVVM体现了软件界面构造方法从过程式向声明式的演进过程。类似的演进在不同领域也曾发生过，数据库查询语句也从命令式代码演进为声明式SQL。可见这是一条必经之路。当下，一场更深刻的变更正在进行中，软件开发活动自身正在从过程式人工编码向声明式AI代码生成演进。当然这篇文章存在很大的发布即过时的风险，原因不在于过程式AI代码生成，而是AI赋能让软件正在从功能容器向能力宿主转变，传统的界面设计工具和方法，无论是用户旅程图、MVC、MVP还是MVVM，可能会快速失去使用场景。