【最新鸿蒙应用开发】——关于鸿蒙MVVM模式的理解

MVVM模式

• MVVM（Model-View-ViewModel）是一种软件设计模式，主要用于分离应用程序的用户界面（UI）和业务逻辑。这种模式可以帮助开发者更高效地开发和管理复杂的用户界面。

  程序的状态数据通常包含了数组、对象，或者是嵌套对象组合而成。在这些情况下，ArkUI采取MVVM = Model + View + ViewModel模式，其中状态管理模块起到的就是ViewModel的作用，将数据与视图绑定在一起，更新数据的时候直接更新视图。

  • Model层：存储数据和相关逻辑的模型。它表示组件或其他相关业务逻辑之间传输的数据。Model是对原始数据的进一步处理。

  • View层：在ArkUI中通常是@Component装饰组件渲染的UI。

  • ViewModel层：在ArkUI中，ViewModel是存储在自定义组件的状态变量、LocalStorage和AppStorage中的数据。

    • 自定义组件通过执行其build()方法或者@Builder装饰的方法来渲染UI，即ViewModel可以渲染View。

    • View可以通过相应event handler来改变ViewModel，即事件驱动ViewModel的改变，另外ViewModel提供了@Watch回调方法用于监听状态数据的改变。

    • 在ViewModel被改变时，需要同步回Model层，这样才能保证ViewModel和Model的一致性，即应用自身数据的一致性。

    • ViewModel结构设计应始终为了适配自定义组件的构建和更新，这也是将Model和ViewModel分开的原因。

目前很多关于UI构造和更新的问题，都是由于ViewModel的设计并没有很好的支持自定义组件的渲染，或者试图去让自定义组件强行适配Model层，而中间没有用ViewModel来进行分离。例如，一个应用程序直接将SQL数据库中的数据读入内存，这种数据模型不能很好的直接适配自定义组件的渲染，所以在应用程序开发中需要适配ViewModel层。

根据上面涉及SQL数据库的示例，应用程序应设计为：

• Model：针对数据库高效操作的数据模型。

• ViewModel：针对ArkUI状态管理功能进行高效的UI更新的视图模型。

• 部署 converters/adapters： converters/adapters作用于Model和ViewModel的相互转换。

  • converters/adapters可以转换最初从数据库读取的Model，来创建并初始化ViewModel。

  • 在应用的使用场景中，UI会通过event handler改变ViewModel，此时converters/adapters需要将ViewModel的更新数据同步回Model。

虽然与强制将UI拟合到SQL数据库模式（MV模式）相比，MVVM的设计比较复杂，但应用程序开发人员可以通过ViewModel层的隔离，来简化UI的设计和实现，以此来收获更好的UI性能。

ViewModel的数据源

ViewModel通常包含多个顶层数据源。@State和@Provide装饰的变量以及LocalStorage和AppStorage都是顶层数据源，其余装饰器都是与数据源做同步的数据。装饰器的选择取决于状态需要在自定义组件之间的共享范围。共享范围从小到大的排序是：

• @State：组件级别的共享，通过命名参数机制传递，例如：CompA: ({ aProp: this.aProp })，表示传递层级（共享范围）是父子之间的传递。

• @Provide：组件级别的共享，可以通过key和@Consume绑定，因此不用参数传递，实现多层级的数据共享，共享范围大于@State。

• LocalStorage：页面级别的共享，可以通过@Entry在当前组件树上共享LocalStorage实例。

• AppStorage：应用全局的UI状态存储，和应用进程绑定，在整个应用内的状态数据的共享。