将代码保留在XAML代码背后的真正优势是什么？

Question

Silverlight社区需要付出很多努力才能将XAML的代码保留在文件后面,尽可能没有代码.这背后的真正动机是什么？

例如,使用命令而不是事件处理程序有什么好处？如果我有

<Button x:Name="SaveButton" Content="Save" Click="SaveButton_Click" />

...

private void SaveButton_Click(object sender, RoutedEventArgs e) {
    _myViewModel.SaveChanges();
}

那为什么这是首选？

<Button x:Name="SaveButton" Content="Save" Command="{Binding SaveCommand}" />

显然SaveCommand,我的视图模型实际上会调用SaveChanges().

这可能导致视图为100%XAML,甚至在XAML中实例化视图模型,并且视图和视图模型之间的连接完全通过绑定完成.当然它很干净,但还有什么呢？灵活？为什么？视图仍然需要使用正确的ViewModel,因此如果两者之间的连接存在且是隐式的,为什么不使它更明确？它还有缺少编译时支持的缺点.如果我将我的按钮挂钩到一个不存在的事件处理程序,编译器会告诉我.如果我绑定到一个不存在的命令,它将不会.

Answer 1

Silverlight社区需要付出很多努力才能将XAML的代码保留在文件后面,尽可能没有代码.这背后的真正动机是什么？

我想说那些希望"尽可能免费提供代码"背后的代码的人是那些在没有真正理解这一点的情况下跳过MVVM的人.(或者你误解了他们的观点).

关键是不要让代码隐藏在代码之外,而是要确保View只负责视觉呈现.可以通过声明方式定义许多视觉方面的事实意味着代码隐藏中的代码更少,但这并不意味着您应该在您觉得有必要的情况下编写代码隐藏,并且不会超出视图的职责范围.

使用命令而不是事件处理程序有什么好处？

命令提供至少两个事件处理程序不具备的功能.某些WPF控件知道Command的CanExecute属性,因此例如,当命令无法执行时,可以禁用按钮.设计器和绑定框架也是Command aware.

如果你只是想在按钮上调用方法,那么使用命令而不是仅仅从事件处理程序调用方法没有什么好处.所以不要害怕使用这种方法.(第三种方法,有利于设计师而不是程序员,是使用Blend 4中的CallMethodAction).

Answer 2

它使单元测试和/或 TDD 更容易。通过使用 MVVM 和命令，我基本上可以构建视图模型和 TDD 风格的命令，并测试大部分视图逻辑，而无需实际使用 XAML 视图。