WPF使用自定义RoutedUICommands还是简单的事件处理程序？

我今天正在和某人谈论如何在他们的WPF程序中选择如何处理逻辑的设计模式,并希望SO社区可以帮助提供进一步的建议以使决策更容易.支持命令的哪些因素超过了不便之处？

我准备了一个完整的示例以及前三种方法的一些UML图:

在按钮和菜单上使用Click事件处理程序.

使用XAML中绑定的命令.

使用绑定在代码中的命令,保留XAML以实现纯GUI布局和样式.

他上过的入门课程和许多书籍都展示了简单的Click事件处理程序,作为将逻辑连接到UI对象的自然方式.

在使用代码隐藏文件中创建的命令时使用命令所需的开销量让他感到有些惊讶:

public static readonly ICommand cmdShow2 = new RoutedUICommand(
  "Show Window2", "cmdShow2", 
  typeof(TestDespatchWindow));

然后在XAML中使用罗嗦的方式编写更多代码,必须识别和绑定命令:

我不能(还)声称自己是WPF专家,所以我可能把事情描绘得比实际情况更复杂,但我怀疑你不能简化事情而不是上述事情.

编辑:

我在DelegateCommand,RoutedCommand和Event之间找到了一个有趣的三向比较.

命令它们的优点和缺点,你必须根据你的情况选择,我强烈建议你在一个案例的基础上做出选择,不要为整个项目选择"一个真正的方法".

对于某些情况,发送方和接收方之间的分离以及仅使用XAML发送命令的能力是一个很大的优势(例如,看看ScrollBar控件模板如何与控制逻辑通信,网址为http://msdn.microsoft.com/en -us/library/ms742173.aspx).

在其他情况下,命令可以将本来是2行事件处理程序变成一些不可能跟随怪物,涉及更改应用程序中的4个单独位置(ViewModel应该如何关闭表单？).