在使用 MVVM 模式创建 WPF 应用程序时，似乎我必须自己收集必要的工具才能开始最基本的事件处理，例如
现在，我正在寻找某种方法来处理 ComboBox 中的 ItemSelected 事件，并获得有关技巧和解决方法的建议（使用 XAML 触发器或将其他元素绑定到所选项目等）。好吧，我可以走这条路，但它似乎是在重新发明轮子。最好有一个可以在 ViewModel 中处理的 ItemSelected 命令。
我是否缺少一些标准工具，或者每个人都在使用 WPF 进行 MVVM 基本上构建和组合他们自己的工具集合，以便他们可以使用事件和命令完成最简单的管道任务，这些事情只需要代码隐藏中的几行使用 Click="eventHandler"？
您对命令的复杂性是正确的。我尝试尽可能地遵循 MV-VM 模式，但我不能证明复杂的变通方法只是为了处理简单的用户事件。
在我看来，如果可以大大简化您的代码，则可以在 View 中处理用户事件。如果您确实在 View 中处理用户事件，您的 View 的代码隐藏应该立即调用 ViewModel 上的方法。这样，您仍将逻辑保留在 ViewModel 中……您只需在 View 中添加一些管道代码（事件处理程序）。我知道 MV-VM 纯粹主义者认为 View 的代码隐藏中不应该有代码，但有时允许一些简单的样板代码（如事件处理程序）更有意义。请记住，其他人将来可能必须阅读/修改您的代码，并且事件处理程序比 DelegateCommand 更容易理解。
根据 Josh Smith 关于 MVVM 的文章，它于 2005 年 10 月在John Gossman 的博客上向全世界揭晓。
从那时起，我会说 WPF/MVVM 还需要 2-3 年才能真正起飞并被社区接受，到那时改造 WPF 以支持 MVVM 的问题已经太迟了。我还要说 WPF 创建了 MVVM，因此让 WPF 更改以支持 MVVM 似乎是倒退的。
最后，不是每个做 WPF 的人都使用 MVVM，所以 API 需要支持事件等的标准使用
因此，要回答您的问题，是的，每个人目前都在将自己的工具集放在一起，因为“官方”支持目前仅提供 DelegateCommands 框架。
很高兴听到我不是唯一一个认为那里的指挥实施是矫枉过正的人。数据绑定似乎很自然地得到了很好的支持，但我一直在努力尝试理解命令绑定，而不是按钮和继承自它的元素。
感谢您发布这个问题。我想从现在开始，我将通过重定向到视图模型函数来处理视图层中的所有事件。我认为这就是他们在 Microsoft 的 XAMLFest 2 天课程之一中教授基本 MVVM 的方式。对我来说已经足够好了！
因为 MVVM 是在 WPF 之后“发明”的……因此为什么 MVVM 的大部分难题不是 WPF 框架的一部分。
不仅如此，MVVM 本身甚至在现实世界中被证明/实践之前就被宣布为“模式”。这与模式的全部意义完全相反——它们通常在许多不同的人成功使用多年后被发现并记录下来。
一个人想出一个模式不是一个模式。
看看这个 VisualStudio 的 MVVM 项目模板。
http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx
使用此模板，您可以获得涵盖 ICommand 不同需求的各种 DelegateCommand 类，以及有助于键绑定的 CommandReference 类。
这是一个好的开始...