MVVM——ArkUI的UI开发模式
MVVM（Model-View-ViewModel）模式简介
MVVM 将应用分为Model、View和ViewModel三个核心部分，实现数据、视图与逻辑的分离。通过这种模式，UI可以随着状态的变化自动更新，无需手动处理，从而更加高效地管理数据和视图的绑定与更新。
ArkUI的UI开发开发模式即是MVVM模式，而状态变量在MVVM模式中扮演着ViewModel的角色，向上刷新UI，向下更新数据，整体框架如下图：
Model：数据访问层。
以数据为中心，不直接与用户界面交互。负责数据结构定义，数据管理（获取、存储、更新等），以及业务逻辑处理。
内容
应用的原始数据提供者。
View：用户界面层。
负责用户界面展示并与用户交互，不包含任何业务逻辑。它通过绑定ViewModel层提供的数据实现动态更新。
内容
-
页面组件
所有应用基本都是按照页面进行分类的，比如登录页，列表页，编辑页，帮助页，版权页等。每个页对应需要的数据可能是完全不一样的，也可能多个页面需要的数据是同一套。
-
业务组件
本身具备本APP部分业务能力的功能组件，典型的就是这个业务组件可能关联了本项目的ViewModel中的数据，不可以被共享给其他项目使用。
-
通用组件
像系统组件一样，这类组件不会关联本APP中ViewModel的数据，这些组件可实现跨越多个项目进行共享，来完成比较通用的功能。
ViewModel：表示逻辑层。
作为连接Model和View的桥梁，通常一个View对应一个ViewModel。View和ViewModel有两种通信方式：
1.方法调用
View通过事件监听用行为，在回调里面触发ViewModel层的方法。例如当View监听到用户Button点击行为，调用ViewModel对应的方法，处理用户操作。
2.双向绑定
View绑定ViewModel的数据，实现双向同步。
内容
-
页面数据
按照页面组织的数据，当用户浏览页面时，某些页面可能不会被显示出来，因此，这个页面数据最好设计成懒加载（按需加载）的模式。
架构核心原则
1. 不可跨层访问
- View层不可以直接调用Model层的数据，只能通过ViewModel提供的方法进行调用。
- Model层数据，不可以直接操作UI，Model层只能通知ViewModel层数据有更新，由ViewModel层更新对应的数据。
2. 下层不可访问上层数据
下层的数据通过通知模式更新上层数据。在业务逻辑中，下层不可直接写代码去获取上层数据。如ViewModel层的逻辑处理，不能去依赖View层界面上的某个值。
3. 非父子组件间不可直接访问
这是针对View层设计的核心原则，一个组件应该具备这样的逻辑：
- 禁止直接访问父组件（必须使用事件或是订阅能力）。
- 禁止直接访问兄弟组件能力。这是因为组件应该仅能访问自己看的见的子节点（通过传参）和父节点（通过事件或通知），以此完成组件之间的解耦。
对于一个组件，这样设计的原因
- 组件自己使用了哪些子组件是明确的，因此可以访问。
- 组件被放置于哪个父节点下是未知的，因此组件想访问父节点，就只能通过通知或者事件能力完成。
- 组件不可能知道自己的兄弟节点是谁，因此组件不可以操纵兄弟节点。
MVVM文件结构
以下是一个备忘录项目的具体文件结构
补充：其他架构模式
1. MVC
- Model（模型）：负责业务数据管理和处理，包括增删改查。Model必须提供外部可以操作模型数据的接口，同时在数据发生变化后能够通知外部
- View（视图）：用户界面。View需要感知Model的变化，数据变化时，更新用户界面
- Controller（控制器）：业务逻辑层。Controller需要感知View的事件，调用Model提供的接口对数据进行操作
工作流程
- 用户对界面进行操作，触发View的相关事件；
- View感知这些事件，通知Controller进行处理；
- Controller处理相关业务，并通过Model的接口对业务数据进行更新；
- Model的业务数据改变触发相应事件，通知View业务数据已经发生改变；
- View捕获到Model发出的数据改变事件，重新获取数据并更新用户界面。
2. MVP
Presenter占据主导地位，充当Model和View的桥梁，实现View和Model两者之间的隔离。
工作流程
- 用户对界面进行操作，触发View的相关事件；
- View感知这些事件，通知Presenter进行处理；
- Presenter处理相关业务，并通过Model的接口对业务数据进行更新；
- Model数据变化会通知Presenter；
- Presenter收到Model数据变化通知后，调用View暴露的接口更新用户界面。