MVVM 中的事件而不是命令？
在MVVM的各种教程中经常会指出，MVVM的目标不是消除代码隐藏，并且代码隐藏中的一些事件处理可能仍然是必要的。
在什么场景下您需要在代码隐藏中编写事件而不是在视图模型中使用命令？
It is often specified in the various tutorials of MVVM, that the goal of MVVM is not to eliminate the code-behind and that some event-handling may still be necessary in the code-behind.
What are the scenarios in which you need to write events in code-behind rather than using commands in viewmodel?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
一般来说，如果您的代码与 UI 逻辑相关，请将其保留在视图的 XAML 或代码隐藏中。视图模型只负责在视图和模型之间桥接和绑定数据。
可以在我的一个问题中找到一个示例，如何通过拖动扩展窗口框架来使 WPF 窗口可移动？ 我使用的事件之一是
SourceInitialized，在其中我访问Window的窗口句柄，用于执行一些 Windows API 魔法。但所有这些都与窗口相关，与窗口之外的应用程序逻辑无关，因此我将其全部限制在窗口的代码隐藏文件中，使视图模型完全不了解它。In general, if your code pertains to UI logic, keep it in the view's XAML or code-behind. The view model is only responsible for bridging and binding data between the view and the model.
An example can be found in one of my questions, How do I make a WPF window movable by dragging the extended window frame? One of the events I use is
SourceInitialized, in which I access theWindow's window handle to perform some Windows API magic. But all this relates to the window, and has nothing to do with application logic beyond the window, so I restrict it all to the window's code-behind file, leaving the view model completely ignorant of it.我认为，在MVVM中，当与UI相关的事件（例如动画）时，您可以在代码隐藏文件中编写。
所有业务逻辑都应该在视图模型中。
In my opinion, in MVVM, when events related to UI, something like animation , you can write in the code-behind file.
All the business logic should be in view model.
根据我的经验，使用不支持 MVVM 绑定的 3rd 方控件将导致在代码隐藏文件中编写代码。即使对于简单的用法（例如选择当前项目、读取当前所选项目等）也会发生这种情况，这在控件中实现起来应该相当简单，但事实并非如此。
这方面的一个示例是 Silverlight TreeView 控件的 SelectedItem 属性，它不是 DependencyProperty（可绑定），而是常规属性，因此您无法绑定。
另外，正如 @BoltClock 提到的，有时将一些代码放在代码后面似乎是合乎逻辑的，这些代码实际上与视图的功能相关，但与视图“背后”的逻辑无关。最好将这些逻辑放在代码隐藏中。
In my experience, using 3rd party controls that do not support MVVM binding will lead to writing code in code behind file. This happened even for simple usages such as selecting current item, reading currently selected item, etc. which should be fairly simple to implement in the control but has not.
A sample of this is SelectedItem property of Silverlight TreeView control, which instead of being DependencyProperty (being bindable) is a regular property so you can not bind to.
Also as @BoltClock mentioned, sometimes it seems logical to put some code in code behind which are really related to what the view does and has nothing to do with the logic "behind" the view. It is best to put these kinds of logic in the code-behind.
您总是会遇到纯粹主义者，他们说代码隐藏文件中不应该有任何代码。我通常是一个纯粹主义者，但在这种情况下不是。
如果您的逻辑非常特定于视图，则应该将其放入代码隐藏文件中。当我编写复杂的视图，需要根据视图模型中的属性或更改对可视化树的结构进行大量更改时，我会将这段代码放在视图中。视图模型不应该了解有关视图的任何信息，因此它不能（也不应该）直接控制这些更改。有时，这些更改可以通过样式或数据模板中的触发器来实现，但有时良好的老式代码是最好的方法。
You are always going to run into purists that say that there should never be ANY code in the code-behind file. I'm usually a purist, but not in this case.
If you have logic that is very specific to the view, it should go in the code-behind file. When I write complicated views that need to make large changes to the structure of the visual tree based on properties or changes in the view model, I put this code in the view. The view model should not know anything about the view, so it can't (and shouldn't) control these changes directly. Sometimes these changes can be implemented with Triggers in a Style or DataTemplate, but sometimes good old fashioned code is the best way.
我认为自定义用户控件有可能使用隐藏代码。
假设您创建了一个继承 TabItem 的 Closable Tab Item 类。您可以使用事件处理该关闭操作并将其绑定到 DP。
这当然是通用的，可以多次使用。
因此，我认为当事件与 UI 而不是 dataModel 或其他活动有关时，后面的代码是可以接受的。
I think that there is the possibility of Custom user controls using code behind.
Let's say you create a Closable Tab Item class that inherits TabItem. You might handle that closing action using events and tie it to a DP.
This is of course generic and could be used multiple times.
So I guess code behind is acceptable when the event has to do with the UI and not the dataModel or other activity.
我遇到的一种情况是使用第三方控制。一些第三方控件（例如 Telerik grid）在内部使用自己的自定义数据类型来表示网格行等，您需要处理各种网格事件以将这些 UI 特定类型转换为您的自定义类型，然后将它们传递给 VM。
One scenario I have come across is with 3'rd party controls. Some 3'rd party controls like telerik grid internally use there own custom data types to represent the grid rows etc and you need to handle the various grid events to convert those UI specific types to your custion types and then pass them to VM.
我想说，如果您要移植到另一个桌面 UI（例如 Mac），则需要不同的任何“逻辑”都应该位于后面的代码中。 （例如具有大约相同逻辑 UI 需求的其他平台）
因此，当使用“悬停”在输入字段上时挂钩所有要分离的事件应该在后面的代码中，但决定当用户“悬停”在输入字段上时在“状态行”中显示什么内容用户确实将鼠标悬停在视图模型中。
I would say any “logic” that would needs to be different if you were porting to another desktop UI (e.g. the mac) should be in the code behind. (E.g. other platform with about the same logical UI needs)
So hooking all the events to detach when the use is “hovering” over an input field should be in the code behind, but deciding what to show in the “status line” when a user does hover should be in the view model.
我没有找到一种很好的方法来处理绑定列表框中多个项目的选择，并且不得不在后面的代码中执行此操作。但这并不是“不干净”
I didn't find a nice way to handle binding the selection of multiple items in listboxes and had to do it in code behind. But it's not "un-clean"