c# - 为什么人们在 ICommand 上使用 CommandManager.InvalidateRequerySuggested()？

Question

我正在制作我自己的一些自定义 ICommand 实现，我看到很多实现都是这样的:

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

protected void RaiseCanExecuteChanged()
{        
    CommandManager.InvalidateRequerySuggested();
}

据我所知，这是优化不佳的代码，因为调用 RaiseCanExecuteChanged() 将触发 UI 中的所有命令以检查它们的 ICommand.CanExecute 状态，通常情况下我们只希望其中之一验证它。

我想我读过一次这是一些 WPF ICommand 的主要代码，比如 RoutedCommand，对他们来说这是有道理的，因为他们想在某些控件失去焦点和类似这样的事情时自动重新验证所有 ICommand ，但我仍然不明白为什么人们会为他们自己的 ICommand 实现重复这种模式。

我想到的代码是一个简单的事件调用，例如:

public event EventHandler CanExecuteChanged;

protected void RaiseCanExecuteChanged()
{        
    CanExecuteChanged?.Invoke(this, EventArgs.Empty);
}

我测试过并且有效，所以为什么网络上的所有示例都没有实现这么简单的东西？我错过了什么吗？

我读过有关在常规事件中使用强引用的内存泄漏问题，其中 CommandManager 仅使用 WeakReferences，这在 View 被垃圾收集的情况下很好，但是尽管如此，是否有任何解决方案不会因内存占用而影响性能？

Answer 1

Why all the examples on the web don't implement something as simple as this? Am I missing something?

我猜这主要是由于懒惰......你提出的确实是一个更好(更有效)的实现。但是，它还不完整:您仍然需要订阅 CommandManager.RequerySuggested 以在命令上引发 CanExecuteChanged。