约什·史密斯 (Josh Smith) 的 RelayCommand 实现是否存在缺陷？

考虑参考Josh Smith 的文章采用模型-视图-视图模型设计模式的 WPF 应用程序 http://msdn.microsoft.com/en-us/magazine/dd419663.aspx，具体来说是一个示例实现RelayCommand（如图 3 所示）。 （这个问题不需要通读整篇文章。）

总的来说，我认为实施情况非常好，但我有一个关于授权的问题CanExecuteChanged订阅了CommandManager's RequerySuggested事件。这的文档RequerySuggested http://msdn.microsoft.com/en-us/library/system.windows.input.commandmanager.requerysuggested%28VS.100%29.aspx states:

由于此事件是静态的，因此它会 只作为弱者抓住处理者 参考。监听的对象 这个活动应该保持强劲 引用他们的事件处理程序 避免它被垃圾收集。这 可以通过拥有一个来完成 私有字段并分配 处理程序作为之前或之后的值 附于本次活动。

然而示例实现RelayCommand不为订阅的处理程序维护任何此类内容：

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

1. 这是否会将弱引用泄漏到RelayCommand的客户端，要求该用户RelayCommand了解实施CanExecuteChanged并自己维护实时参考？

2. 如果是这样，是否有意义，例如修改RelayCommand如下所示，以减轻潜在的过早 GCCanExecuteChanged订户：

   // This event never actually fires.  It's purely lifetime mgm't.
   private event EventHandler canExecChangedRef;
   public event EventHandler CanExecuteChanged
   {
       add 
       { 
           CommandManager.RequerySuggested += value;
           this.canExecChangedRef += value;
       }
       remove 
       {
           this.canExecChangedRef -= value;
           CommandManager.RequerySuggested -= value; 
       }
   }
   

我在乔什的书中找到了答案comment http://joshsmithonwpf.wordpress.com/2008/03/18/understanding-routed-commands/#comment-10430在他的“了解路由命令 http://joshsmithonwpf.wordpress.com/2008/03/18/understanding-routed-commands/“ 文章：

[...]您必须在 CanExecuteChanged 中使用 Wea​​kEvent 模式 事件。这是因为视觉元素会挂钩该事件，并且因为 命令对象可能永远不会被垃圾回收，直到应用程序 关闭时，内存泄漏的可能性非常大。 [...]

论点似乎是这样的CanExecuteChanged实现者只能弱地保留已注册的处理程序，因为 WPFVisuals他们太愚蠢了，连自己都解脱了。这最容易通过委托给来实现CommandManager，谁已经这样做了。大概是出于同样的原因。