如何在MVVM中构建ViewModel而不违反单一职责原则？
罗伯特·马丁 (Robert Martin) 说：“一个类发生变化的原因永远不应该超过一个”。
让我们考虑绑定到视图的 ViewModel 类。 ViewModel 可能（甚至很可能）由彼此并不真正相关的属性组成。 对于小视图，ViewModel 可能非常一致，但是当应用程序变得更加复杂时，ViewModel 将公开可能会因不同且不相关的原因而发生更改的数据。
我们是否应该担心 ViewModel 类的 SRP 原则？
Robert Martin says: "There should never be more than one reason for a class to change".
Let's consider the ViewModel class which is bound to a View. It is possible (or even probable) that the ViewModel consists of properties that are not really related to each other. For small views the ViewModel may be quite coherent, but while the application gets more complex the ViewModel will expose data that will be subject to change for different and unrelated reasons.
Should we worry about the SRP principle in the case of ViewModel class or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
ViewModel 的单一职责是向 View 提供它所需的信息。 如果视图需要不同且不相关的属性，那并不重要，因为 ViewModel 只有一个更改原因，那就是视图显示不同的属性。 所以你不用太担心。
也就是说，如果 ViewModel 确实变得巨大，也许您可以考虑将视图划分为多个子视图，以提高可重用性并保持视图和 ViewModel 的可管理性。
The ViewModel single responsibility is to provide the View the information it needs. If the View needs different and unrelated properties that is not important as the ViewModel only has one reason to change and that is the View showing different properties. So you shouldn't worry too much.
That said, if the ViewModel does get huge, maybe you could think about dividing the view into several subviews to improve reusability and keep the Views and the ViewModels manageable.
我同意 gcore 的观点。
一旦您看到 ViewModel 增长到超过两屏的文本，就应该考虑将 ViewModel 拆分为多个子模型。
另一个经验法则是，我在 XAML 文件中的嵌套从来不会超过两层——如果视图的一部分变得太复杂，那么就需要进行视图重构了——将内部 XAML 提取到单独的 UserControl 中并创建相应的 ViewModel，其中将是子视图上的默认数据上下文。
I agree with gcores.
Once you see ViewModel grow to more than two screenfuls of text, it is time to consider splitting ViewModel into several child models.
Another rule of thumb is that I never have more than two levels of nesting inside XAML file -- if one part of the view becomes too complex, it is time for view refactoring -- extract inner XAML into separate UserControl and create corresponding ViewModel, which will be default data context on child view.
是的，但这并不意味着糟糕的设计不能迫使你这样做。
Yes, but that doesn't mean poor design couldn't force you into it.
我同意将屏幕拆分为具有多个 ViewModel 的多个视图对于减少臃肿和复杂性是必要的。 这是我用来帮助坚持使用 MVVM 的 SRP 的另一种模式：
这是一个场景。 我的 ViewModel 需要获取数据并响应来自 UI 的过滤器命令。 我创建的 ViewModel 的结构是复合的。 也就是说，有权访问 ViewModel 私有成员的子类执行线性任务，例如处理过滤。 我可能还有另一个子类，它执行根据标准选择项目所需的逻辑。 你明白了。 一旦 ViewModel 执行跨多个方法的某些功能，它可能是委托给子类的良好候选者。 子类仍然是主 ViewModel 的一部分，因此它只是减小 ViewModel 大小并使单元测试这些线性操作更容易的一种方法。
I agree that splitting your screens into multiple Views with multiple ViewModels is necessary to reduce bloat and complexity. Here's another pattern I've employed to help stick to SRP using MVVM:
Here's one scenario. My ViewModel needs to obtain data and respond to filter commands from the UI. I create the ViewModel to be composite in structure. That is, child classes that have access to private members of the ViewModel perform linear tasks such as handling the filtering. I might also have another child class that performs the necessary logic for selection of items based on criteria. You get the idea. Once the ViewModel is performing certain functions that span across several methods, it may be a good candidate to delegate to a child class. The child classes remain part of the main ViewModel, so it's just a way of reducing the size of the ViewModel and makes unit testing these linear operations easier.