Wpf 当前的MVVM视图模型实践是否违反了单一责任原则？

根据当前的实践（至少使用WPF和Silverlight），我们可以看到视图模型中通过命令绑定绑定的视图，或者至少可以看到视图模型中处理的视图事件。这似乎违反了，因为视图模型不仅对视图状态建模，而且对视图（用户）做出响应。其他人问过或问过（最后一个是MVC中的控制器，但大致类似）

那么，目前的做法是否违反了SRP？或者“视图模型”真的是一组不违反SRP的东西吗？为了更好地理解这一点，我们似乎需要知道什么是单一责任，或者概念中是否有多重责任，是否划分出符合SRP的个人责任。我不确定

视图模型说

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

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

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

在一篇关于视图模型角色的文章中，作者说（再次强调）

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

• 观点的抽象
• 命令
• 值转换器
• 视图状态

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

建模视图状态的单一“模糊”责任（那么我们该怎么做 （按州平均）

多重责任（视图状态、用户交互（即。 （命令）

单一特定职责的组合（抽象， 状态、交互、转换），因此具有单个 责任：“管理所有这些东西”

如果您感到好奇，我会“关心”这一点，因为（2）感觉是对的，但似乎与当前的实施背道而驰。

单一责任是：

“一个类改变的原因不应该超过一个。”

就MVVM而言，ViewModel实际上只是

因此，表示模型应该只表示UI的状态，而表示者/控制器应该始终在UI和表示模型之间协调命令。如果遵循这一思想，SRP根据状态和命令进行划分，那么添加命令不应影响表示状态的类。因此，MVVM将破坏SRP

然而。。。 我认为这是在抓救命稻草。MVVM是一个相当专门的实现，基本上用于WPF/Silverlight（）

模式的设计目的是使设计更简单，而替代方案可能更麻烦或不易维护。由于MVVM是为了利用表示技术极其丰富的数据绑定功能而设计的，所以这是一个值得权衡的选择

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

• 观点的抽象
• 命令
• 值转换器
• 视图状态

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

至于其余的，你是对的。在某些情况下。我构建的应用程序中，值转换和维护视图状态的任务非常复杂，单个视图模型类无法完成所有任务，因此我将它们划分为单独的类，与虚拟机进行互操作

---

所以呢？

不！MVVM不违反SRP，（程序员违反了，lol！）

没有理由使用MVVM模式需要忽略SRP。MVVM并不意味着只有一个模型类、一个视图模型类和一个视图类。当然，如果只有一个视图类，则只能显示一个简单的屏幕

视图层中的类应该负责一件事；做、决定或包含。一个视图可以由多个子视图组成，这些子视图的任务是执行某些用户操作。考虑一个基本的形式，它有一个显示网格，网格中的项目可以被编辑，并且有一个“保存”按钮。 主视图将是另外两个视图的容器；datagrid（用户控件或其他东西）和命令控件。然后，datagrid负责选择正确的子视图来呈现数据；本质上，它是一个数据绑定的容器。要编辑项的视图是datagrid的子视图，而datagrid又是主视图的子视图。最后，命令控件是一组按钮（在本例中是单个按钮），其唯一职责是发出用户已发出命令的信号

这样，编辑视图（由DataGrid使用）对使用它的内容是不可知的，并且有一个责任；命令控件也是如此。同样，DataGrid不关心谁使用它，只关心它可以包含编辑视图（子视图）。那里的SRP不错

匹配视图（和子视图）的视图模型还有一个原因。编辑视图模型是编辑视图绑定到的容器；它只包含可以显示/编辑的数据字段。当它的一个属性发生变化时，它只关心信号。Command-Button视图模型是一个执行以下操作的类。它的命令被绑定到按钮上，它将根据用户单击的内容进行工作。它必须能够访问ViewModel的其他部分才能执行其工作

主页视图模型包含其他子视图。它的唯一责任是作为初始值设定者，生成所有必需的ViewModel实例，并传递constru