当前的 MVVM 视图模型是否违反了单一职责原则？

Question

根据当前的做法（至少使用 WPF 和 Silverlight），我们看到通过视图模型中的命令绑定绑定的视图，或者我们至少看到在视图模型中处理的视图事件。这似乎违反了SRP，因为视图模型不仅对视图状态建模，而且对视图（用户）做出响应。其他人问过how to build view models without violating SRP或者问过whether their implementations do so（最后这个是MVC中的控制器，但大致类似）。

那么当前的做法是否违反了 SRP？还是“视图模型”真的是不违反 SRP 的东西的集合？稍微概括一下，似乎我们需要知道什么是单一职责，或者概念中是否有多个职责，是否将各个职责分开，符合 SRP。我不确定。

Wikipedia's definition of view model 说

[T]ViewModel 是“视图的模型”，这意味着它是视图的抽象，也用于视图和模型之间的数据绑定

这对于 SRP 来说似乎已经足够了，但是后来的条目说（我的重点补充了）

[ViewModel] 充当数据绑定器/转换器，将模型信息更改为视图信息并将命令从视图传递到模型

在关于视图模型角色的Prism blog post 中，作者说（再次强调）

归结起来，视图模型是以下内容的组合：

• 视图的抽象
• 命令
• 价值转换器
• 查看状态

我确定我错过了很多定义，但它们似乎属于以下类别：

1. 建模视图状态的单一“模糊”责任（那我们该怎么办？ 意思按州）
2. 多重职责（视图状态、用户交互（即 命令））
3. 单个特定职责的组合（抽象、 状态、交互、转换），因此只有一个 责任：“管理所有这些东西”。

如果您好奇，我会“关心”这一点，因为 (2) 感觉不错，但似乎与流行的实现背道而驰。

Answer 1

单一职责为Martin defines it：

“改变课程的理由不应该不止一个。”

就 MVVM 而言，ViewModel 实际上只是 Presentation Model 的专门实现。

因此，尽管有人认为 Presentation Model 应该只代表 UI 的 状态，而 Presenter/Controller 应该始终在 UI 和 Presentation Model 之间代理命令。如果遵循这个想法，SRP 划分状态和命令，那么添加命令应该不会影响表示状态的类。因此 MVVM 会破坏 SRP。

但是...

我认为这是在抓住稻草。 MVVM 是一种相当专业的实现，主要用于 WPF/Silverlight (and now browser clients)。

模式旨在使设计更简单，替代方案会更麻烦或更难维护。由于 MVVM 旨在利用表示技术极其丰富的数据绑定功能，因此这是一个值得权衡的选择。

Answer 2

不！ MVVM 不违反 SRP，（程序员确实如此，哈哈！）

没有理由使用 MVVM 模式需要忽略 SRP。 MVVM 并不意味着只有一个 Model Class、一个 View-Model Class 和一个 View Class。当然，如果你只有一个 View Class，你就只能显示一个简单的屏幕。

视图层中的那些类应该负责一件事；做、决定或包含。一个视图可以由几个子视图组成，它们的工作是完成某些用户交互。考虑一个基本的表单，它有一个显示网格，网格中的项目可以编辑，还有一个“保存”按钮。

主视图将是其他两个视图的容器；数据网格（用户控件或其他东西）和命令控件。然后数据网格负责选择正确的子视图来呈现数据；从本质上讲，它是一个数据绑定的容器。用于编辑项目的视图是数据网格的子视图，而数据网格又是主视图的子视图。最后，命令控件是一组按钮（在本例中为单个按钮），它们的唯一职责是发出用户已发出命令的信号。

通过这种方式，编辑视图（由 DataGrid 使用）对于使用它的内容是不可知的，并且有一个责任；与命令控制相同。同样，DataGrid 不关心谁使用它，只关心它可以包含编辑视图（子视图）。不错的 SRP。

与视图（和子视图）匹配的视图模型也负责一件事。编辑视图模型是编辑视图绑定的容器；它只包含可以显示/编辑的数据字​​段。它不关心任何事情，只关心其属性之一发生变化时的信号。命令按钮视图模型是一个做事的类。它的命令绑定到按钮，它会根据用户点击的内容来工作。它必须能够访问 ViewModel(s) 的其他部分才能完成工作。

主页视图模型用于包含其他子视图。它的唯一职责是作为初始化程序，创建所有必需的 ViewModel 实例，并将构造函数参数传递给其他 ViewModel 实例（例如，命令按钮视图模型，以便它知道从哪里获取数据以进行工作）

将一大堆功能塞进一个大视图将绑定到的单个 ViewModel 是很自然的。但不一定非得如此，SRP 可以在 MVVM 中维护。

MVVM 的主要目标是允许可测试的设计，Model 层可以独立测试，Model 中的所有类都可以轻松遵循 SRP。 ViewModel 可以在不需要视图的情况下进行测试；在 ViewModel 中考虑 SRP 变得更加棘手，但它肯定是可行的；只要记住打破你的课程，这样他们就只有一个问题。视图绑定到部分视图模型，如果运气好的话，您对视图模型的测试使得捕捉视图变得超级容易。请记住，您可以让每个 View-let 都遵守 SRP，成为更大的综合视图（容器）的一部分。

TL;博士？ 为了直接回答您的问题，视图是不破坏 SRP 的类的集合。因此，当 ViewModel 从 View(s) 中抽象出来时（View-First），它们也是遵循良好 SRP 的类的集合。

Answer 3

我认为当前围绕 MVVM 的许多做法（至少）违反了 SPR。这是另一种情况，只需将控制器添加回 MVVM 即可干净地解决所有问题。我称之为 MVCVM :)

我们在最近的所有项目中成功使用的模式是仅在模块中注册控制器，并在启动时对其进行初始化。控制器非常轻巧/纤薄，是应用程序生命周期中唯一需要监听或发送消息的东西。然后在他们的初始化方法中注册他们需要拥有的任何东西（视图和视图模型等）。这种轻量级的仅内存逻辑模式也使应用程序更轻薄（例如，更适合 WP7）。

正如您所发现的，仅使用 VM 的问题在于，最终您会遇到他们需要了解视图、命令或其他不应该涉及自尊的 ViewModel 的东西的情况！

我们遵循的基本规则是：

• 控制器根据事件做出决策
• 控制器获取数据并将其放置在适当的视图模型属性中
• 控制器设置视图模型的 ICommand 属性以拦截事件
• 控制器使视图出现（如果其他地方没有暗示）
• 视图模型是“愚蠢的”。用于绑定的保持数据和nothing else
• 视图知道它们显示某种形状的数据，但不知道它来自哪里

最后两点是你永远不应该打破的，否则关注点分离会消失。

简单地将控制器添加回 MVVM 组合似乎可以解决我们发现的所有问题。 MVVM 是个好东西，但为什么它们不包括控制器呢？ (但这当然只是我的看法) :)

Answer 4

归结起来，视图模型是以下内容的组合：

• 视图的抽象
• 命令
• 价值转换器
• 查看状态

我不明白您为什么将前两项分开。命令是视图的一部分。

至于其余的 - 你是对的。在某些情况下。我已经构建了应用程序，其中值转换和维护视图状态的任务非常复杂，以至于单个视图模型类无法完成所有工作，我将它们分解为与 VM 互操作的单独类。

那么？