wpf – 目前的MVVM视图模式做法是否违反单一责任原则？

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

目前的做法是否违反SRP？还是“查看模式”真的是不违反SRP的东西的集合？为了构想这一点，似乎我们需要知道单一责任是什么，或者在概念中有多重责任，个人责任是否符合SRP。我不确定。

Wikipedia’s definition视图模型说

[T]he ViewModel is a “Model of the View” meaning it is an abstraction of the View that also serves in data binding between the View and the Model

这似乎对SRP来说足够好，但是后来的条目说(我的重点是加了)

[The ViewModel] acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model

作者在Prism blog post号关于观察模式的作用时说，(再次，我的重点)

What it boils down is that the view model is a composite of the following:

• an abstraction of the view
• commands
• value converters
• view state

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

>单一“模糊”的建模视图状态的责任(所以我们做什么
按状态)
>多重责任(查看状态，用户互动(即
命令))
>单一具体责任(抽象，
状态，交互，转换)，因此有一个单一的
责任：“管理所有的东西”。

如果你好奇，我“关心”这一点，因为(2)觉得正确，但似乎与现行的实现相反。

单一责任为 Martin defines it：

“THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.”

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

因此，尽管可以认为演示模型只能表示UI的状态，而演示者/控制器应该总是在UI和演示模型之间进行代理。如果遵循这个想法，使用SRP划分状态和命令，那么添加命令不应该影响表示状态的类。因此MVVM将破坏SRP。

然而…

我认为这是抓住稻草。 MVVM是一个相当专门的实现，基本上在WPF / Silverlight(and now browser clients)中使用。

模式旨在使设计更简单，替代方案会更麻烦或更不易维护。由于MVVM旨在利用演示技术的极其丰富的数据绑定功能，因此它是一个有价值的交易。