为什么WPF / Visual不支持MVVM中的事件和命令？

Question

当使用MVVM模式创建WPF应用程序时，似乎必须自己收集必要的工具，甚至开始最基本的事件处理。

• AttachedBehaviors我从这里那里得到的
• DelegateCommands我从这里那里得到的

现在，我正在寻找一种在ComboBox中处理ItemSelected事件的方法，并获得关于技巧和解决方案的建议(使用XAML触发器或将其他元素绑定到所选项，等等)。好的，我可以沿着这条路走，但它似乎是在重新发明方向盘。最好有一个ItemSelected命令，我可以在ViewModel中处理它。

是我缺少了一些标准工具，还是每个人都在用WPF进行MVVM --基本上是构建和组装他们自己的工具集合--这样他们就可以用事件和命令来完成最简单的管道任务，在代码中只需要几行代码--用Click="eventHandler“进行隐藏？

Answer 1

根据乔希·史密斯关于MVVM的文章，它是2005年10月在约翰·高斯曼博客上向全世界发布的。

从那时起，我会说，WPF/MVVM需要2到3年的时间才能真正起飞，并被社区所接受。到那时，对WPF进行改造以支持MVVM的问题为时已晚。我还想说，WPF创建了MVVM，因此WPF的更改似乎是向后的，以支持MVVM。

最后，并非每个做WPF的人都使用MVVM，所以API需要支持事件等的标准使用。

因此，为了回答您的问题，是的，每个人目前都在将自己的一组工具放在一起，因为“官方”支持目前只提供DelegateCommands框架。

Answer 2

关于命令的复杂性，你是对的。我试图尽可能地遵循M模式，但我不能仅仅为了处理一个简单的用户事件而证明复杂的解决方案。

在我看来，如果视图中的用户事件大大简化了您的代码，那么处理它是可以的。如果您确实在视图中处理用户事件，则视图的代码隐藏应该立即调用ViewModel上的一个方法。这样，您仍然将逻辑保留在ViewModel…中视图中只有一些管道代码(事件处理程序)。我知道M纯粹主义者认为视图的代码背后不应该有代码，但有时允许一些简单的样板代码(比如事件处理程序)更有意义。记住，其他人将来可能不得不阅读/修改您的代码，而且理解事件处理程序要比DelegateCommand容易得多。

Answer 3

很高兴听到的消息是，我并不是唯一一个认为外部的主要实现是过度使用的人。Databinding看起来支持得很好，但是几个星期来，我一直在努力理解除了按钮和继承它的元素之外的其他东西的命令绑定。

谢谢你贴出这个问题。我想，从现在开始，我将通过重定向视图模型函数来处理视图层中的所有事件。我认为这就是他们在微软的XAMLFest 2天课程中教授基本MVVM的方式。对我来说已经够好了！