`ICommand.CanExecuteChanged` 应该如何实现？ [关闭]

Question

背景

在看Josh Smith关于CommandGroup的文章时，我注意到网上有很多关于如何实现ICommand.CanExecuteChanged的cmets。

在 StackOverflow 上发布了一个类似的问题 here，但是

1. 我觉得没有明确的答案，并且
2. 评论中没有足够的空间来添加额外的上下文。

供参考：

1. Josh Smith 的原始 article 关于 CommandGroup 使用了一个简单的 .NET 事件
2. Josh Smith 的 RelayCommand 使用 CommandManager implementation 的 CanExecuteChanged
3. 微软自己的RoutedCommand使用CommandManagerimplementation的CanExecuteChanged
4. Microsoft 自己的 PRISM 库（版本：6）还 uses 一个简单的 .NET 事件（以前的版本使用弱引用）

我的问题

我对 WPF 比较陌生，我想知道应该如何在 Josh Smith 的 CommandGroup 中实现 CanExecuteChanged 事件以避免任何意外行为或内存泄漏？

补充阅读

Josh Smith: Aggregating WPF Commands with CommandGroup

Josh Smith: WPF apps with the MVVM design pattern

StackOverflow: Is Josh Smith's implementation of the RelayCommand flawed?

StackOverflow: comment about CanExecuteChanged

Microsoft: RoutedCommand

PRISM 6: DelegateCommandBase

Answer 1

假设您将命令绑定到按钮。当按钮即将被呈现时，它会调用 CanExecute() 并根据结果呈现为启用或禁用。 WPF 在“它决定”时自动调用 CanExecute()，但你不应该继续这种行为。

因此，当你实现 ICommand 时，声明一个像 UpdateCommand() 这样的方法，当你决定时它会引发有问题的事件。 例如，如果点击一个按钮启动了一个缓慢的操作，一旦前一个按钮完成后应该再次触发，您应该引发两次事件 - 一次在开始操作之前，一次在完成之后。

没有“实现 ICommand.CanExecuteChanged 的​​最佳方式”之类的东西。可能这就是不随框架提供 ICommand 的默认实现的部分原因。 大多数 MVVM 框架，提供默认实现：RelayCommand、ActionCommand、ParameterCommand、AsyncCommand 等。 他们只是让事情变得更容易——通过一个代表，你就可以开始了。 Josh Smith 的文章解决了一个不同的问题，这是一种在 XAML 中链接多个路由命令的巧妙方法。

一般：

1. 将 ICommand 与 MVVM 结合使用
2. 在创建可重用控件并且希望命令在可视化树中冒泡时使用 RoutedCommand，以便有兴趣的人可以处理它
3. 你可以使用装饰器设计模式来装饰你所有的命令， 这样您就可以添加上层功能，例如仅对特权用户有效的命令，一次禁用所有命令等。只需确保装饰器订阅了实际命令的 CanExecuteChanged 并代表它重新触发事件