WPF 命令系统的控制权转移：从 DelegateCommand 到自定义实现

目标读者：理解 MVVM 基础、想搞清楚 CanExecute 为何能自动驱动 Button.IsEnabled 的 WPF 开发者。

阅读收获：建立"控制权转移"的架构视角，看清 Prism 与自定义 ICommand 之间的等价与差异。

---

一、什么是"控制权转移"

传统 WinForm 时代，按钮的可用性由开发者在 TextChanged 事件里手动设置：

// WinForm 风格：UI 事件主动设置状态
textBox.TextChanged += (s, e) => saveButton.Enabled = !string.IsNullOrEmpty(textBox.Text);

WPF 的 Command 模式则反过来了——业务层声明状态，UI 层被动响应：

// MVVM 风格：业务逻辑决定按钮状态
SaveCommand = new DelegateCommand(Save, () => !string.IsNullOrEmpty(Name) && Age > 0);

一句话：控制权从"UI 事件处理代码"转移到了"ViewModel 的 CanExecute 委托"。这就是 MVVM 区别于事件驱动编程的本质。

---

二、IsEnabled 与 CanExecute 的关系：叠加而非覆盖

很多人会困惑：明明 XAML 里设了 IsEnabled="True"，按钮却显示为灰色。这不是 Bug，正是 WPF 命令系统的设计：

<Button IsEnabled="True" Command="{Binding SaveCommand}" Content="保存" />

WPF 加载时序：

1. 创建 Button 实例
2. 设置 IsEnabled = True
3. 解析 Command 绑定
4. 调用 Command.CanExecute() 获取初始状态
5. 如果返回 false → 渲染层强制叠加为禁用

最终的交互状态 = IsEnabled（父级/手动） && Command.CanExecute()。代码里读 Button.IsEnabled 仍然是 True，但按钮是灰色的——因为命令状态作为"逻辑启用状态"被叠加到了 UI 渲染层。

为什么是叠加而不是覆盖？ 因为 IsEnabled 还要兼顾父容器禁用、手动禁用等其他约束，多层"逻辑与"才是正确模型。

---

三、Prism 的 DelegateCommand：精准式刷新

Prism 的方案是显式声明依赖 + 精准刷新：

SaveCommand = new DelegateCommand(Save, CanSave)
    .ObservesProperty(() => Name)   // 显式告诉框架：我依赖 Name
    .ObservesProperty(() => Age);

底层链路（详见上一篇文章）：

Name 变化 → PropertyObserver 捕获 → RaiseCanExecuteChanged
         → CommandManager.InvalidateRequerySuggested()
         → WPF 重查 CanExecute → 按钮状态更新

特点：只刷新显式声明了依赖的命令，性能更可控；缺点是开发者必须显式列出所有依赖属性。

---

四、自定义 ICommand：广播式刷新

我曾自己实现过一个最简 ICommand：

public class TangdaoCommand : ICommand
{
    private readonly Action _execute;
    private readonly Func<bool> _canExecute;

    public event EventHandler CanExecuteChanged
    {
        add    { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }

    public TangdaoCommand(Action execute, Func<bool> canExecute = null)
    {
        _execute = execute;
        _canExecute = canExecute;
    }

    public bool CanExecute(object parameter) => _canExecute?.Invoke() ?? true;
    public void Execute(object parameter) => _execute();
}

4.1 它为什么能工作

关键在事件访问器：所有对 CanExecuteChanged 的订阅都被转发到了全局的 CommandManager.RequerySuggested。

• WPF 按钮绑定命令时调用 CanExecuteChanged += handler
• 我的 add 访问器把 handler 转交给 CommandManager
• CommandManager 在鼠标移动、焦点变化等时机触发 RequerySuggested
• 所有订阅过的命令（无论实例）都重新查询 CanExecute

4.2 它和 Prism 的本质差异

维度	TangdaoCommand	DelegateCommand
触发机制	广播（依赖 CommandManager）	精准（PropertyObserver 监听指定属性）
刷新粒度	所有命令一起刷	只刷显式声明的命令
依赖声明	不需要	必须 .ObservesProperty(...)
性能	UI 交互频繁时可能浪费	精准控制
代码量	20 行	几百行 + PropertyObserver 体系

架构师视角：在小型项目里，TangdaoCommand 完全够用且更简洁；只有当命令数量多、CanExecute 计算昂贵时，才需要 Prism 这种精准控制。

---

五、CommandManager.RequerySuggested 到底是什么

它是一个全局静态事件，由 WPF 在特定时机主动触发：

触发场景	是否触发
鼠标移动	✅
键盘按下/释放	✅
窗口激活/失焦	✅
控件焦点变化	✅
CommandManager.InvalidateRequerySuggested()	✅
点击按钮执行命令	❌
手动改 Button.IsEnabled	❌

最后两条是常见误解。RequerySuggested 监测的是"状态可能变了"的信号，而不是"命令被调用"的事件——执行命令本身不会改变 CanExecute 的返回值。

sender 永远为 null，因为它由 CommandManager 内部调度器触发，没有具体"发送者"。

5.1 一段诊断代码

// 在 CanExecute 里加日志，移动鼠标观察
public bool CanExecute(object parameter)
{
    Console.WriteLine("CanExecute 被调用");
    return _canExecute?.Invoke() ?? true;
}

你会发现控制台刷屏——这正是 RequerySuggested 在 WPF 消息循环里被频繁触发的直观证据。WPF 用性能换实时性，确保任何状态下 UI 都与业务状态严格一致。

---

六、内存隐患与边界

TangdaoCommand 那种"转发到 CommandManager"的写法有内存风险吗？分场景看：

订阅者	风险	原因
WPF 控件（Button、MenuItem）	安全	WPF 内部用 WeakEventManager 订阅
长生命周期单例服务	安全	本来就不该回收
短生命周期对象 + 忘记 -=	⚠️ 泄漏	CommandManager 强引用委托，阻止 GC

具体剖析见下一篇文章《WPF 事件系统的三大总枢》。

---

七、实战：完整的保存按钮

public class UserViewModel : BindableBase
{
    private string _name;
    public string Name { get => _name; set => SetProperty(ref _name, value); }

    private int _age;
    public int Age { get => _age; set => SetProperty(ref _age, value); }

    public TangdaoCommand SaveCommand { get; }

    public UserViewModel()
    {
        SaveCommand = new TangdaoCommand(Save, CanSave);
    }

    private bool CanSave() => !string.IsNullOrEmpty(Name) && Age > 0;
    private void Save() { /* 持久化逻辑 */ }
}

<Button Content="保存" Command="{Binding SaveCommand}" />

输入 Name 或 Age 时，按钮自动启用/禁用——没有任何手动 PropertyChanged 订阅代码。这就是"控制权转移"带来的工程价值：

1. UI 与业务解耦：ViewModel 不知道按钮存在，按钮不写事件处理
2. 状态一致性：按钮、菜单、工具栏绑定同一个 Command，状态永远一致
3. 可测试：CanSave() 是纯函数，无需启动 UI 即可验证
4. 自动化：依赖属性变化时按钮自动响应，零胶水代码

---

八、总结

模式	谁控制按钮	代价
事件驱动（WinForm）	事件处理代码	UI 耦合、逻辑分散、难测试
DelegateCommand + ObservesProperty	业务逻辑（精准）	必须显式声明依赖
自定义 ICommand + CommandManager	业务逻辑（广播）	无需声明依赖，全局刷新有性能开销

架构师建议：90% 的业务场景用自定义 ICommand 就够了；只有当 CanExecute 计算昂贵或命令数量爆炸时，再引入 Prism 的 ObservesProperty。不要为了"看起来专业"而引入复杂度。