MVVM：命令与事件处理程序
我知道这已经完成了，但大多数答案都是“是的，如果你愿意，你可以使用事件处理程序代替命令”。这仍然不能解决是否需要编写复杂命令与仅在代码后面连接事件处理程序以调用视图模型中的可测试方法的问题。
我不喜欢命令，因为它们会生成大量样板代码，并且与普通方法相比没有给我带来任何好处，而且其中一些命令（例如拖放）实施起来很痛苦。
编写以下内容有什么问题：
codebehind:
private void Button_Click(object sender, RoutedEventArgs e)
{
viewModel.LoadData();
}
viewmodel:
public void LoadData()
{
//....
}
这与任何命令一样可测试（如果不是更多）。 IMO，只要特定于 UI 的内容没有泄漏到您的业务逻辑中，就真的没有必要在这样的复杂模式上浪费时间。想法？
I know this has been done to death, but most answers are along the lines of "yeah, you can use eventhandlers in place of commands if you like". This still doesn't solve the problem of whether writing complicated commands is warranted vs just wiring up eventhandlers in code behind to call testable methods in your view model.
I don't like commands because they produce a lot of boilerplate code and don't give me any benefit over normal methods, plus some of them (such as drag & drop) are a pain to implement.
What's wrong with writing:
codebehind:
private void Button_Click(object sender, RoutedEventArgs e)
{
viewModel.LoadData();
}
viewmodel:
public void LoadData()
{
//....
}
This is equally testable (if not more) as any command is. IMO, as long as UI specific stuff isn't leaking into your business logic, there's really no need to waste time on complicated patterns like that. Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在大多数情况下，
。如果您小心地将业务逻辑保留在代码隐藏文件之外，那么使用代码隐藏并没有什么问题。这是将其直接委托给 ViewModel，这是合理的。
话虽这么说，但在长期可维护性方面存在一些潜在的缺陷：
ICommand允许您拥有相同的视图可以与可能不同的视图模型一起使用。 （然而，这在实践中很少见。）Nothing - for the most part.
There is nothing wrong with using code behind, if you are careful to keep the business logic out of the code behind file. This is delegating this directly to the ViewModel, which is reasonable.
That being said, there are a couple of potential downfalls here in terms of long term maintainability:
ICommandallows you to have the same View be used with potentially different ViewModels. (This is rare in practice, however.)我一开始就在你的船上，我什至基本上问了 同样的问题在这里。但我后来发现自己真的很喜欢命令。
有些命令本身确实足够复杂，需要进行测试。它们与视图模型上的其他任何东西一样可测试。
ICommand还包括CanExecute和CanExecuteChanged，它使您的视图能够智能地启用/禁用自身，而且几乎免费。这在复杂的视图中非常棒。命令使您可以更轻松地更改视图，大多数控件都有一个可以绑定的 Command 属性，并且简单地移动绑定比使用事件处理程序更容易。如果您有设计人员处理 XAML，则尤其如此。
您几乎可以在视图不存在的情况下编写视图的整个逻辑。它导致了一次构建所有内容的良好流程，然后立即将界面全部放在上面。
将代码保存在一处可以实现长期的可维护性。
I was in your boat at first, I even asked basically the same question here. But I came around and came to really like commands.
Some commands really are complex enough in and of themselves to warrant testing. They are just as testable as anything else on your viewmodel.
ICommandalso includesCanExecuteandCanExecuteChanged, which enables your view to intelligently enable/disable itself pretty much for free. This is fantastic in complex views.Commands make it easier to change your view around, most controls have a Command property you can bind to, and simply moving the binding around is easier than mucking with event handlers. This is especially true if you have designers working on the XAML.
You can pretty much write the entire logic of the view without the view even existing. It leads to a nice flow of build the meat all at once, then throw the interface on top all at once.
Keeping your code in one place leads to longer term maintainability.
对我来说，反对事件的一个非常重要的论点是迫使 UI 设计者编写代码来测试视图。更糟糕的是：每次他重新设计视图时，他都必须重新连接事件。
Blend 中的命令和行为使这个过程变得过时并且更加容易。
在编写事件处理程序时实际使用事件参数时可能会出现另一个问题。当您想要切换到另一个控件或另一个事件时，您可能会变得非常依赖于事件参数，从而很难切换，因为其他控件/事件不支持相同的事件参数。
To me a very important argument against events is forcing the UI Designer to write code to be able to test a View. And worse: every time he redesigns the View he has to rewire the events.
Commands and the behaviors in Blend make render this process obsolete and much easier.
Another problem might arise when actually using the event arguments when writing the event handler. When you want to switch to another control or another event you might have become very dependent on the event arguments making it hard to switch because the other control/event does not support the same event arguments.