严格遵守 MVVM 模式？答案

【问题标题】：Rigid adherence to the MVVM pattern?严格遵守 MVVM 模式？
【发布时间】：2012-03-19 03:46:13
【问题描述】：

我正在构建一个 WPF 应用程序并第一次使用 MVVM。总体而言，使用 MVVM 非常有趣，主要好处之一是视图和模型类之间的良好分离。不将它们混合在一起是一种纪律（至少是年轻的开发人员）。

我们有一个场景，在确认消息框后单击按钮时需要关闭窗口。现在这可以通过处理按钮单击事件并在 Window 类本身中关闭窗口来实现旧方式。或者我们可以通过在 ViewModel 中创建命令，调用 Window 来显示消息框..等来实现 MVVM 方式。

我明白这里需要做什么，但我的问题是 - 是否有必要在所有情况下都使用 MVVM 命令？是否有我们不应该使用命令的例外情况，例如简单的 UI 操作？我们不是在这里过度使用 MVVM 吗？以 MVVM 方式做所有事情的好处究竟是什么？

【问题讨论】：

我刚刚发布了一篇关于组织命令用法和对话框的简单（甚至是简单化）方法的博客文章，虽然它适用于基于 Metro 的 XAML 应用程序，但我认为它本身就是一种有用的命令方法. See it here.

标签： wpf mvvm

【解决方案1】：

或者我们可以通过在 ViewModel 中创建命令，调用 Window 来显示消息框..等来实现 MVVM 方式。

让我把这个分开，主要是因为 IMVHO 我一直看到这个做错了 - 很多人试图在 VM 中做太多事情。首先，问自己一个问题：

提示是否与数据或业务规则有任何关系？

如果不是，即它只是一个“你真的确定吗？”输入提示，那么这应该完全在视图后面的代码中完成。视图模型需要了解或采取任何行动的唯一时间是它实际上与视图模型有关，在这种情况下，您应该从 VM 公开命令，但实际的窗口关闭仍然是从视图背后的代码。

VM 应该对它所绑定的视图一无所知，这是 MVVM 模式的目的之一。它可以公开命令，但它不应该知道用户已经与特定的 UI 元素交互¹，也不应该直接知道窗口即将关闭。虚拟机可以提示（通过对话服务，你确实有，是吗？）当前数据未保存，但它通常不知道窗口，因为它不知道它的数据是如何的呈现。

有时您会走得更远，很容易过度分析是否应该纯粹从视图、纯粹从 VM 完成某事，还是两者兼而有之。如果您记得 VM 的角色，并记住在视图中保留代码是可以的（前提是它只执行与视图相关的内容并将 VM 内容交给 VM），那么 99% 的时间您不会有问题。

¹ 例如，VM 不应该知道或关心用户是否只是单击了按钮、超链接或触摸了图像中的热点。可以使用相同的命令来处理任何此类问题。

【讨论】：