MVVM：我应该从我的Execute方法中检查我的“CanExecute”方法吗？

Question

我了解使用的CanExecute()和Execute()，但我想了解一下下面的场景：

public class MyViewModel : NotificationObject 
{ 
    public MyViewModel() 
    { 
     FooCommand = new DelegateCommand(DoFoo, CanDoFoo); 
    } 

    public Bar MyBar { get; set; } 

    public DelegateCommand FooCommand { get; private set; } 

    public Boolean CanDoFoo() 
    { 
     return (MyBar != null) 
    } 

    public void DoFoo() 
    { 
     MyBar.BarFunc(); //Potential for a NullReferenceException 
    } 
} 

基本上，消费观点可以决定直接调用DoFoo方法（显然打破了ICommand点接口）并导致NullReferenceException。这可能有点主观，但我希望有一个“标准”的方式来做到这一点。

难道我们：

1. 防止可能的NullReferenceException通过做if (MyBar != null)第一？
2. 通过验证CanDoFoo()是否返回true来防止可能的NullReferenceException？
3. 假设消费视图行为正常，并且已经验证它可以调用DoFoo()方法？

---

作为一个侧面说明，主要的原因，我问这是因为当我在写单元测试，我意识到，有人可以通过调用 Execute()方法，而不调用其 CanExecute()同行打破我的ViewModel？显然在我的单元测试中，我检查看看我是否可以在执行该方法之前执行该方法，但消费视图可能会决定忽略该方法。

---

更新：（方案2）

，作为扩展到这个问题，我也想在该DoFoo()方法不会在异常处理方面打破方案添加，但能够打破逻辑？

public class MyViewModel : NotificationObject 
{ 
    public MyViewModel() 
    { 
     FooCommand = new DelegateCommand(DoFoo, CanDoFoo); 
    } 

    public Int32 Age { get; set; } 

    public DelegateCommand FooCommand { get; private set; } 

    public Boolean CanDoFoo() 
    { 
     return (Age >= 21) 
    } 

    public void DoFoo() 
    { 
     ProvideAlcohal(Age); 
    } 
} 

这第二个方案实际上并没有中断（命令可以很好地处理），但是，它在逻辑上分解了。那么，我们是否需要通过调用CanDoFoo()来验证业务逻辑，或者假设消费视图正在运行？ （请记住，这只会打破业务逻辑）。

基本上归结为这个......我们是否采取了预防措施以确保消费者的视线不会因为行为不当而在脚下自己拍摄？

Answer 1

任何执行命令调用WPF或Silverlight将做到这一点的，所以你不必从UI系统的担心......

但它是一个公共方法。检查null是你能做的最快速的事情之一。它没有伤害，并且它更安全，因为您将抛出一个没有guard子句的空异常。

从语义上讲，CanExecute可能会执行不同于空检查，所以我只是在Execute方法做空检查，不一定检查CanExecute。