是事件，而不是MVVM中的命令？

如何解决是事件，而不是MVVM中的命令？

| MVVM的各种教程中通常都指定了MVVM的目标不是消除背后的代码，而在背后的代码中仍可能需要某些事件处理。 在哪些情况下需要在代码背后编写事件而不是在viewmodel中使用命令？     

解决方法

通常，如果您的代码与UI逻辑有关，则将其保留在视图的XAML中或隐藏在代码中。视图模型仅负责在视图和模型之间桥接和绑定数据。 在我的一个问题中可以找到一个示例：如何通过拖动扩展的窗框使WPF窗口移动？我使用的事件之一是“ 0”，在其中访问“ 1”的窗口句柄以执行一些Windows API魔术。但是所有这些都与窗口有关，并且与窗口之外的应用程序逻辑无关，因此我将所有内容都限制在窗口的代码隐藏文件中，而视图模型完全不了解它。     ,我认为，在MVVM中，当与UI相关的事件（如animation）时，您可以在代码隐藏文件中编写。 所有业务逻辑都应在视图模型中。     ,以我的经验，使用不支持MVVM绑定的第3方控件将导致在文件后面的代码中编写代码。即使对于简单的用法（例如选择当前项目，读取当前选择的项目等），也会发生这种情况，这在控件中应该很容易实现，但实际上并不是。 一个示例是Silverlight TreeView控件的SelectedItem属性，该属性不是DependencyProperty（可绑定）是常规属性，因此您无法绑定到该属性。 就像@BoltClock提到的那样，有时在代码中放置一些与视图的工作确实相关并且与逻辑“在视图后方”无关的代码似乎是合乎逻辑的。最好将这些逻辑放在后面的代码中。     ,您总是会遇到纯粹主义者，他们说在代码隐藏文件中绝对不应有任何代码。我通常是一个纯粹主义者，但在这种情况下不是。 如果您有非常特定于视图的逻辑，则应将其放在代码隐藏文件中。当我编写复杂的视图时，需要根据属性或视图模型的更改对可视化树的结构进行大的更改，我会将这段代码放在视图中。视图模型应该对视图一无所知，因此它不能（也不应该）直接控制这些更改。有时，可以使用Style或DataTemplate中的Triggers来实现这些更改，但是有时，良好的老式代码是最好的方法。     ,我认为自定义用户控件可能在后面使用代码。 假设您创建一个继承TabItem的Closable Tab Item类。您可以使用事件处理该关闭操作，并将其绑定到DP。 这当然是通用的，可以多次使用。 因此，我认为当事件与UI有关而不是与dataModel或其他活动有关时，可以接受后面的代码。     ,我遇到的一种情况是使用第三方控制。一些第三方控件（例如telerik grid）在内部使用自己的自定义数据类型来表示网格行等，并且您需要处理各种网格事件，以将这些特定于UI的类型转换为您的custion类型，然后将它们传递给VM。     ,我要说的是，如果要移植到另一个桌面UI（例如mac），则需要与之不同的任何“逻辑”都应该在后面的代码中。 （例如，其他具有大致相同的逻辑UI需求的平台） 因此，在使用“悬停”在输入字段上时，应将所有事件挂接以使其分离，但应在视图模型中确定用户悬停在“状态行”中显示的内容。     ,我没有找到一种很好的方法来绑定列表框中的多个项目，因此只能在后面的代码中完成。但这不是“不干净的”