# uFrame MVVM Core 分析

日期：2026-06-12

## 结论

uFrame MVVM 的核心价值不在它的 Kernel、IOC 启动或代码生成器，而在运行时 MVVM 的几个机制：

- `ViewModel` 持有可观察状态。
- `P<T>` 把 ViewModel 属性包装成可订阅的数据流。
- `Signal<TCommand>` 把 UI 操作表达成命令流。
- `ViewBase` 通过 `Bind / Unbind` 管理订阅生命周期。
- `ViewService` 负责把 View 与 ViewModel 对接。

但这套 MVVM 被 uFrame 自身的全局 Kernel、全局容器、命名约定、`Resources.Load` 和设计器生成代码强绑定。它可以作为反面边界样本和局部机制参考，不适合作为 FlowScope Kernel 或 UI 模块的直接原型。

FlowScope 可以吸收“可观察状态 + 命令流 + 绑定生命周期作用域”，但不应吸收它的全局 IOC 查找、ViewModel 自动解析、Controller 命名约定和资源自动定位。

## 源码范围

本次分析基于 `uFrame/uFrame.MVVM` 当前公开仓库源码，重点阅读：

- [`ViewModel.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/ViewModel.cs)
- [`ModelPropertyBase.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/ModelPropertyBase.cs)
- [`Signal.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/ViewModels/Signal.cs)
- [`ViewBase.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/ViewBase.cs)
- [`View.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/View.cs)
- [`Controller.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Controllers/Controller.cs)
- [`ViewService.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Services/ViewService.cs)
- [`MVVMKernelExtensions.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/MVVMKernelExtensions.cs)
- [`ViewBindings.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Bindings/ViewBindings.cs)
- [`ViewResolver.cs`](https://github.com/uFrame/uFrame.MVVM/blob/master/uFrame.MVVM/Source/Runtime/Views/ViewResolver.cs)

## 运行时结构

uFrame MVVM 的运行时可以拆成五组对象：

```text
ViewModel 层
  ViewModel
  P<T>
  ModelCollection<T>
  Signal<TCommand>
  ViewModelCommand

View 层
  ViewBase
  View<TModel>
  ViewComponent
  ViewBindings

创建与连接层
  Controller
  ViewService
  ViewResolver

绑定层
  Binding
  ModelPropertyBinding
  ModelViewPropertyBinding
  ModelViewModelCollectionBinding

全局基础设施
  uFrameKernel.Container
  IEventAggregator
  SystemService / SystemServiceMonoBehavior
```

它不是一个独立、纯粹的 MVVM runtime。`ViewModel`、`View`、`Controller` 和 `ViewService` 都会触碰 uFrame Kernel 或全局容器。

## ViewModel

`ViewModel` 是所有生成 ViewModel 的基类。它承担了状态、绑定、序列化、事件发布、销毁通知等多种职责。

关键职责：

- 通过 `FillProperties` 暴露属性元信息。
- 通过 `FillCommands` 暴露命令元信息。
- 持有 `Bindings`，用于释放订阅。
- 持有 `Identifier`，用于全局容器按 id 查找。
- 通过 `PropertyChanged` 通知属性变化。
- `Dispose` 时发布 `ViewModelDestroyedEvent`。

问题是它太重。一个干净的 ViewModel 应该主要表达 UI 状态和 UI 意图，但这里的 `ViewModel` 混入了：

- 序列化协议。
- `IBindable`。
- `IDisposable`。
- 全局事件聚合器。
- binding 容器。
- 引用计数。
- controller wiring hook。

这会让 ViewModel 从“状态对象”变成“框架对象”。长期项目里，这种设计会让测试、复用和生命周期判断都变复杂。

## P<T>

`P<T>` 是 uFrame MVVM 最值得看的部分。它把单个属性封装成 observable property：

```csharp
public class P<T> : ISubject<T>, IObservableProperty, ISimpleNotifyPropertyChanged
```

它提供：

- `Value`：当前值。
- `LastValue`：上一次值。
- `ChangedObservable`：只在值变化时通知。
- `ObjectValue`：非泛型访问入口。
- `Owner`：所属 ViewModel。
- `PropertyName`：属性名。
- `ToComputed`：根据其他 observable property 计算派生值。

View 侧可以订阅 `P<T>`，属性变化时刷新 UI。这个机制适合 Unity UI，因为它避免了大量手动 `Refresh()` 和每帧轮询。

可取点：

- 属性变化可以显式订阅。
- 派生属性可以声明依赖。
- View 绑定时可以立即应用当前值。
- IDisposable 可以挂到绑定作用域统一释放。

风险点：

- `Value` setter 没有先比较新旧值，任何赋值都会触发通知。
- `Owner` 让 property 反向知道 ViewModel。
- `P<T>` 同时实现 subject、property、notify，职责偏多。
- `ChangedObservable` 依赖 `Value` 和 `LastValue` 的外部状态，语义不够直观。

FlowScope 如果吸收这个思路，应改成更小的 `ObservableProperty<T>`：

```text
只负责保存值、比较值、发布变化、释放订阅。
不要知道全局 Kernel。
不要知道 View。
不要知道资源或 Controller。
```

## Signal<TCommand>

`Signal<TCommand>` 用来表达 ViewModel 命令：

```csharp
public class Signal<TClass> : ISubject<TClass>, ISignal<TClass>
    where TClass : IViewModelCommand, new()
```

它的行为是：

1. View 或绑定层构造 command。
2. 调用 `Signal.OnNext(command)`。
3. `Signal` 把 `Sender` 设置为当前 ViewModel。
4. 执行本地 `Action`。
5. 推送给订阅者。

这个方向是好的：UI 操作不应该直接调用业务系统，而应该变成可观察的 command 或 intent。

可取点：

- UI 输入被建模为显式命令。
- 命令可以订阅、组合、测试。
- View 与业务处理之间不需要直接互相引用。

风险点：

- command 的 sender 被 `Signal` 自动写入，有隐式副作用。
- 命令流最终仍然容易接到全局 EventAggregator。
- 生成器会为每个命令生成强约定代码，手写维护成本高。

FlowScope 可以吸收 command stream，但建议命名为更中性的 `UIIntent` / `ViewAction` / `FeatureCommand`，并放在 feature scope 内，不进入 Kernel core。

## ViewBase / View<TModel>

`ViewBase` 是 View 与 ViewModel 的连接点。它提供：

- `ViewModelObject`：当前绑定的 ViewModel。
- `Bind()`：用户编写订阅逻辑。
- `PreBind()`：生成器插入绑定逻辑。
- `AfterBind()`：绑定完成后的 hook。
- `Unbind()`：释放绑定。
- `AddBinding()`：把 disposable 放到当前 View 的绑定列表。
- `BindOnStart`：是否启动时自动绑定。
- `DisposeViewModelOnDestroy`：View 销毁时是否销毁 ViewModel。

`View<TModel>` 只是给 `ViewBase` 加了泛型 Model 访问：

```csharp
public abstract class View<TModel> : ViewBase where TModel : ViewModel, new()
```

可取点：

- View 的绑定逻辑有明确生命周期。
- 订阅统一挂到 binding scope。
- View 只响应 ViewModel 的状态，不需要每帧刷 UI。
- View 销毁时可以集中释放订阅。

问题点：

- `ViewBase.KernelLoaded()` 会调用 `uFrameKernel.Container.Inject(this)`。
- `OnDestroy()` 依赖 `uFrameKernel.IsKernelLoaded` 和全局事件。
- View 的 `Bindings` 实际挂在 `ViewModelObject.Bindings[ViewId]` 上，View 和 ViewModel 的生命周期互相缠住。
- `References` 引用计数用于判断 ViewModel 是否销毁，复杂且脆弱。

FlowScope 可以借鉴 `Bind / Unbind / AddBinding`，但绑定容器应属于 View 或 feature-local binding scope，而不是塞进 ViewModel。

## Controller

uFrame 的 `Controller` 是特殊的 `SystemService`，主要负责创建和初始化 ViewModel。

流程大致是：

```text
Controller.Create(identifier)
  -> CreateEmpty(identifier)
  -> RegisterViewModel(vm, identifier)
  -> Initialize(vm)
  -> Publish ViewModelCreatedEvent
```

问题在于 `CreateEmpty` 内部直接注册到全局容器：

```text
uFrameKernel.Container.RegisterViewModel(vm, identifier)
```

`MVVMKernelExtensions.CreateViewModel(type)` 又会通过 ViewModel 类型名去全局容器找 Controller：

```text
Resolve<Controller>(type.Name)
```

这是强命名约定 + 服务定位器。它表面上把 ViewModel 创建集中到了 Controller，实际上把依赖关系藏进全局容器和类型名字符串。

FlowScope 不应该吸收这套 Controller 模式。更合适的是：

```text
Feature 明确创建 ViewModel。
Feature 明确创建/绑定 View。
FeatureContext 提供本 feature 需要的服务。
UI module 不通过全局容器按名字找 Controller。
```

## ViewService / ViewResolver

`ViewService` 负责：

- 监听 `InstantiateViewCommand`。
- 根据 ViewModel 找 View prefab。
- 实例化 View。
- 在 View 创建时补齐 ViewModel。
- View 销毁时移除记录。
- ViewModel 销毁时从全局容器移除实例。

`ViewResolver` 默认根据 ViewModel 类型名找 prefab：

```text
PlayerViewModel -> Player -> Resources.Load("Player")
```

这是老式 Unity 框架常见做法，但不适合 FlowScope：

- 资源路径是隐式命名约定。
- 默认绑定到 `Resources.Load`。
- 不支持现代资源后端的显式 handle、group、release。
- 不利于 Addressables / YooAsset / AssetBundle / 自定义资源系统适配。
- View 的创建和 ViewModel 的创建混在同一个服务里。

FlowScope 如果需要 UI 模块，可以把它拆成：

```text
IViewFactory
  负责创建 View，不负责创建 ViewModel。

IViewBinder<TView, TViewModel>
  负责绑定和解绑。

IUIViewRegistry 或 IViewCatalog
  负责显式注册 view key 到 prefab/address。

IResourceService adapter
  负责真实资源加载和释放。
```

## Binding

uFrame 的 binding 层包括：

- `Binding`
- `ModelPropertyBinding`
- `ModelViewPropertyBinding`
- `ModelViewModelCollectionBinding`
- `ViewBindings` 扩展方法

最实用的是 `ViewBindings.BindProperty`：

```text
立即用当前值刷新一次 UI。
订阅后续变化。
把 IDisposable 加入 bindable 的绑定列表。
```

这是 FlowScope 可以吸收的重点：

```csharp
bindingScope.Bind(vm.Title, value => titleText.text = value);
```

但不要吸收它的反射绑定和生成器绑定作为 core。反射/生成器可以是工具层能力，不应该成为 UI runtime 的基本前提。

## 与 FlowScope Kernel 的关系

uFrame MVVM 不应该进入 FlowScope Kernel core。

FlowScope Kernel 已经明确应保持机制小核：

```text
Container
AppKernel
StartupPipeline
FeatureHost
FeatureInstance
FeatureContext
FeatureLifetime
FeatureSlot
FeaturePolicy
```

MVVM 属于更高层的 UI module 或 feature-local module。Kernel 最多提供 feature 生命周期和上下文，不提供：

- ViewModel 基类。
- View 自动绑定。
- UI prefab 查找。
- 命令总线。
- 全局 ViewService。
- 全局事件聚合器。
- 全局 IOC 注入 View。

推荐边界：

```text
FlowScope.Kernel
  只负责 Feature 生命周期和 Slot/Policy 机制。

FlowScope.UI
  提供 ViewModel、ObservableProperty、BindingScope、ViewBinder。

FlowScope.Resources
  提供资源加载接口和后端适配。

Game Feature
  自己声明 ViewModel、View、Binder、Command handler。
```

## 可吸收清单

可以吸收：

- `ObservableProperty<T>` 思路。
- `ObservableCollection<T>` 思路。
- UI command / intent stream。
- `Bind / Unbind` 生命周期。
- `IDisposable` binding scope。
- View 订阅 ViewModel，ViewModel 不直接操作 View。
- View 创建和 ViewModel 绑定分离。
- 集合绑定生成子 View 的思路，但要显式管理资源释放。

不应吸收：

- `uFrameKernel.Container` 全局创建 ViewModel。
- `Container.Inject(view)`。
- 按 `ViewModel` 类型名查找 `Controller`。
- 按 `ViewModel` 类型名 `Resources.Load` prefab。
- ViewModel 持有 View 绑定列表。
- ViewModel 引用计数决定销毁。
- 全局 EventAggregator 作为 UI command 默认通道。
- 代码生成器作为 runtime 必需条件。
- ViewModel 同时承担序列化、绑定、事件、销毁、controller hook。

## FlowScope 可采用的最小 UI MVVM 形态

建议的最小形态：

```text
ObservableProperty<T>
  保存值并发布变化。

BindingScope
  持有 IDisposable 列表，Dispose 时统一释放。

IViewModel
  标记 UI 状态对象，不依赖 Kernel。

IViewBinder<TView, TViewModel>
  Bind(view, vm, scope)
  Unbind 由 scope.Dispose 承担。

UIView<TViewModel>
  MonoBehaviour，只持有 Unity UI 引用和当前 ViewModel。

UICommand<T>
  feature-local command，不走全局事件总线。
```

示意：

```csharp
public sealed class BindingScope : IDisposable
{
    private readonly List<IDisposable> _items = new();

    public T Add<T>(T item) where T : IDisposable
    {
        _items.Add(item);
        return item;
    }

    public void Dispose()
    {
        foreach (var item in _items)
            item.Dispose();

        _items.Clear();
    }
}
```

```csharp
public sealed class MainMenuViewModel
{
    public ObservableProperty<string> Title { get; } = new("Main Menu");
    public Subject<StartGameIntent> StartGame { get; } = new();
}
```

```csharp
public sealed class MainMenuBinder
{
    public void Bind(MainMenuView view, MainMenuViewModel vm, BindingScope scope)
    {
        scope.Bind(vm.Title, value => view.TitleText.text = value);
        scope.Add(view.StartButton.OnClickAsObservable()
            .Subscribe(_ => vm.StartGame.OnNext(new StartGameIntent())));
    }
}
```

关键点是：这里没有全局容器查找，没有 `Resources.Load` 约定，没有 Kernel 注入 View，也没有 ViewModel 引用计数。

## 最终判断

uFrame MVVM 的局部机制比它的 Kernel 更有参考价值，但必须拆开看。

真正值得保留的是：

```text
状态可观察
操作命令化
绑定有生命周期
View 不直接写业务
```

必须避免的是：

```text
全局容器创建一切
命名约定连接一切
ViewModel 变成框架对象
资源加载隐藏在 ViewResolver
UI 模块污染 Kernel core
```

对 FlowScope 来说，uFrame MVVM 最好的用途不是成为模板，而是提醒我们：UI MVVM 应该是 Kernel 之上的可选模块，且必须保持 feature-local、显式绑定、显式资源、显式生命周期。