我有一个有点奇怪的问题，但你的意见对我来说很有趣。
让我们想象一下，我们已经在 WPF 或 Silverlight 中实现了 Command，并且由于某些原因，在不正确的状态下调用了 Execute 方法，即使 CanExecute 返回 false。不管它是如何发生的，但它确实如此。当然，我们不能正确执行命令，因为我们的状态不正确，但是怎么办呢？
我们应该忽略这种情况吗？但我们可能会错过一些严重的问题。
我们应该抛出异常吗？但是我们都生活在异步世界中，所以理论上可以执行检查，返回 true 为 CanExecute，然后状态可能会更改为不正确，并且将在不正确的状态下调用 Execute。所以，我们按照要求做了一切，但我们有一个例外。
所以，请让我知道你的想法是什么？
你的 CanExecute 不应该太长太复杂以至于这实际上是一个问题。
如果在运行 Execute 时再次检查 CanExecute（如果您没有在 CanExecute 中做坏事，这将同步发生），那么您可以做的更多。您的业务规则应该在通往数据存储库的过程中捕获与业务相关的问题，并且作为执行结果调用的任何其他函数也可以进行自己的验证和数据检查。
如果 发生这种情况，那么对我来说，这意味着您在 CanExecute 的某个地方有问题。或者可能没有调用 CanExecute （可能更改了属性并且没有重新评估命令）。
除非你给出这个行为不端的代码的一个可靠的例子，否则这就是我能说的最多的。
在 Execute 方法中调用 CanExecute 是没有问题的，但是如果我们得到 false 怎么办？我们只需要退出吗？
是的，你可以退出。或者，您可以抛出与验证相关的异常（不推荐，因为您通常会通过绑定调用它）。基本上 Execute 是链条的开始，任何调用它的人或任何东西都应该被设置为处理错误——你永远不应该仅仅因为它被调用就期望成功。
但是，如果我的同事创建了一个使用我的命令的组件并且在调用 Execute 之前忘记检查 CanExecute 怎么办？
在这种情况下，我会说在视图模型中实现命令然后绑定到它是不好的。如果该命令是在视图后面的代码中实现的，则可以从那里调用视图模型以执行所需的任何工作（例如保存一些数据），并将该调用包装在 try/catch 中，如果你捕获一个例外，您可以轻松地在 UI 中显示某些内容（如果您正确遵守 MVVM，则从 VM 中是不可能的）。
请记住：绑定到命令很棒，但没有人说命令都必须在视图模型中。甚至 CanExecute 也可以调用视图模型，以便进行数据验证 - 如果您是一名优秀的编码人员，那么视图所需的视图模型上的所有方法/属性都通过接口公开。