为什么ICommand比调用VM的代码更好？

Question

我有一位同事问我为什么要使用ICommand模式。

他想添加一个按钮，然后在后面的代码中为它创建一个事件。然后从事件中他想在ViewModel上调用一个方法。

我给了他明显的答案：这增加了View和ViewModel之间的耦合。但他认为View和ViewModel已经耦合了。 （我们将视图的DataContext设置为后面的View代码中的ViewModel：DataContext = new MyViewModel();

是的，我告诉他，他的方式增加了“更多耦合”，但对我来说听起来有点蹩脚。

所以，我知道ICommand是干净的方式，我这样做。但除了不使用现有的耦合器之外，ICommand还会给你带来什么呢？

Answer 1

• 这不是解耦，而是你可以深入了解ModelView层次结构：不是事件抽，而是事件路由，内置于框架中

• 关于UI managent：命令有状态（CanExecute），如果将命令分配给控件，如果命令状态变为false，则控制变为禁用状态。它为您提供了强大的UI状态管理方式，避免了大量的意大利面条编码，尤其是复杂的UI。

Answer 2

  

我有一位同事问我为什么要使用ICommand   图案。

似乎暗示这是贵公司的标准（无论明确说明还是未说明）。这应该足以回答他的问题了。

如果所有公司代码都应该使用该模式，那么当其他人必须调试他的代码时，它可能会导致共同开发者混淆和沮丧。

此外，在我看来，使用ICommand开发/模拟的速度更快，因为您不需要在上下文中使用ICommand属性来运行程序。它让你的UI设计师（如果你有幸拥有它们）完全完成他们的任务，即使你已经落后于你的编码。

Answer 3

ICOMmand还可以为您提供处理或不处理特定按钮的权利。这将通过canexecute方法处理。

Answer 4

您可以将命令的CanExecute方法绑定到控件的属性，同时Command以一种很好的方式封装操作。在我看来/经验中，这种方法很有意义，因为你在一个抽象中同时具有条件和执行操作，这使得它更容易理解和测试。

如果将来您发现此操作重复，您可以在自己的自定义ICommand中轻松地对其进行抽象，并在多个位置使用它。

Answer 5

我在之前的答案中没有看到的一件事是，使用ICommand通过允许不同的GUI组件使用相同的操作来促进代码重用。例如，如果我有一个应该导致打开窗口的命令，并且该命令可以在三个或应用程序中的不同屏幕中调用，那么ICommand实现允许我在一个地方定义该逻辑。使用代码隐藏事件处理程序，我必须复制并粘贴冗余代码，这违反了DRY（否则，我必须通过抽象到类来完成我自己的实现，此时，我不妨使用ICommand的）。