C# 命令模式实现方法 C#如何将请求封装成对象

命令模式的核心是将“调用”封装为可存储传递的对象，通过ICommand接口统一抽象操作，实现调用方与接收者的松耦合；命令应仅转发请求给接收者，避免内嵌业务逻辑，并按需支持Undo、参数校验、上下文注入及生命周期管理。

命令模式的核心是把“调用”变成可存储、可传递的对象

在 C# 中，命令模式不是靠语法糖实现的，而是靠接口抽象和对象封装。关键在于定义一个统一的 ICommand 接口，让所有请求（比如保存、撤销、发送邮件）都实现它，从而抹平操作差异。这样你就能把 button.Click += SaveHandler 这类紧耦合逻辑，换成 button.Command = new SaveCommand(document) 这种松耦合结构。

常见错误是直接在 Execute() 里写业务逻辑，导致命令类无法复用或测试；正确做法是让命令只负责“转发”，把具体动作委托给接收者（Receiver）——比如 SaveCommand 持有 Document 实例，Execute() 里只调用 _document.Save()。

ICommand 接口必须包含 Execute 和 Undo（如果需要撤销）

基础命令至少要有 Execute()；支持撤销时，必须同步提供 Undo()，且两者语义要对称。注意：不是所有命令都需要 Undo()，比如“发送短信”这种不可逆操作，接口可以不定义它，或者实现为空——但别抛异常，否则调用方得处处 try-catch。

• ICommand 接口通常不带泛型，避免过度设计；如需传参，用构造函数注入，而不是在 Execute(Object param) 里塞 object
• 参数应提前验证：比如 DeleteCommand(Guid id) 在构造时就检查 id != Guid.Empty，而不是等到 Execute() 才报错
• 若命令依赖外部状态（如当前用户权限），不要在 Execute() 里实时查数据库——应在创建命令时把必要上下文（如 CurrentUser）作为只读字段传入

使用委托构造命令可快速原型，但不适合复杂场景

对于简单交互（比如按钮点击触发单行逻辑），可用 Action 封装：

public class SimpleCommand : ICommand {     private readonly Action _execute;     private readonly Action _undo; <pre class="brush:php;toolbar:false;">public SimpleCommand(Action execute, Action undo = null) {     _execute = execute;     _undo = undo; }  public void Execute() => _execute(); public void Undo() => _undo?.Invoke();

}

但这类命令无法序列化、不能带状态、难以调试。一旦涉及重做（Redo）、日志记录、权限校验或异步执行，就得退回到完整类实现——比如把 SaveCommand 的 Execute() 改成 async Task ExecuteAsync()，并继承 IAsyncCommand（自定义接口）。

命令队列与 Invoker 是解耦关键，别让 UI 层直接 new Command

真正体现命令模式价值的地方，是把命令的“生成”“调度”“执行”彻底分离。UI 层（如 ViewModel）只负责创建命令实例并交给 Invoker，而 Invoker 管理执行顺序、事务包装、异常兜底。例如：

• Invoker 可以批量执行命令并统一提交数据库事务
• 历史记录功能只需维护一个 Stack<icommand></icommand>，每执行一个就 Push()，点撤销就 Pop().Undo()
• 避免在 Button_Click 里直接 new SaveCommand(doc) —— 应通过工厂或 DI 容器获取，否则单元测试时无法 Mock 接收者

最容易被忽略的是命令的生命周期管理：如果命令持有大对象引用（如整个 DataTable），又没及时释放，会引发内存泄漏。建议在 Execute() 后清空敏感字段，或用 IDisposable 显式释放。