我正在制作自己的一些自定义 ICommand 实现，我看到很多实现都是这样的：
public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
protected void RaiseCanExecuteChanged()
{
CommandManager.InvalidateRequerySuggested();
}
据我所知，自从调用以来，这是优化不佳的代码RaiseCanExecuteChanged()将触发 UI 中的所有命令来检查其ICommand.CanExecute状态，而通常我们只想其中之一来验证它。
我想我读过一次，这是一些 WPF ICommands 的主要代码，例如RoutedCommand，对他们来说这是有道理的，因为一旦某些控件失去焦点和类似的事情，他们希望自动重新验证所有 ICommand，但我仍然不明白为什么人们会为自己重复这种模式ICommand实施。
我想到的代码是一个简单的事件调用，例如：
public event EventHandler CanExecuteChanged;
protected void RaiseCanExecuteChanged()
{
CanExecuteChanged?.Invoke(this, EventArgs.Empty);
}
我测试过，这有效，所以为什么网络上的所有示例都没有实现这么简单的东西？我错过了什么吗？
我读过有关在常规事件中使用强引用的内存泄漏问题，其中CommandManager只使用WeakReferences，这在视图被垃圾收集的情况下很好，但仍然，是否有任何解决方案不会影响内存占用的性能？
为什么网络上的所有示例都没有实现这么简单的东西？我错过了什么吗？
我猜这主要是由于懒惰......您提出的确实是一个更好（更有效）的实现。但是，它并不完整：您仍然需要订阅CommandManager.RequerySuggested募集CanExecuteChanged在命令上。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
