罗伯特·马丁说：“改变班级的理由不应该不止一个”。
让我们考虑绑定到视图的 ViewModel 类。 ViewModel 有可能（甚至很可能）由彼此并不真正相关的属性组成。对于小视图，ViewModel 可能非常一致，但是当应用程序变得更加复杂时，ViewModel 会暴露数据，这些数据会因不同且不相关的原因而发生变化。
对于 ViewModel 类，我们是否应该担心 SRP 原则？
【问题讨论】：
标签： wpf silverlight mvvm solid-principles
ViewModel 的唯一职责是向 View 提供它需要的信息。如果 View 需要不同且不相关的属性，这并不重要，因为 ViewModel 只有一个改变的原因，那就是 View 显示不同的属性。所以你不用太担心。
也就是说，如果 ViewModel 确实变得很大，也许您可以考虑将视图分成几个子视图以提高可重用性并保持 View 和 ViewModel 的可管理性。
【讨论】：
我同意 gcores。
一旦您看到 ViewModel 增长到超过两屏的文本，是时候考虑将 ViewModel 拆分为多个子模型了。
另一个经验法则是，我在 XAML 文件中的嵌套级别永远不会超过两级——如果视图的一部分变得过于复杂，则该进行视图重构——将内部 XAML 提取到单独的 UserControl 中并创建相应的ViewModel，这将是子视图的默认数据上下文。
【讨论】：
是的，但这并不意味着糟糕的设计不能强迫你去做。
【讨论】：
我同意将您的屏幕拆分为具有多个 ViewModel 的多个视图对于减少臃肿和复杂性是必要的。这是我用来帮助坚持使用 MVVM 的 SRP 的另一种模式：
这是一种情况。我的 ViewModel 需要获取数据并响应来自 UI 的过滤命令。我将 ViewModel 创建为复合结构。也就是说，有权访问 ViewModel 的私有成员的子类执行线性任务，例如处理过滤。我可能还有另一个子类，它执行基于标准选择项目的必要逻辑。你明白了。一旦 ViewModel 执行跨越多个方法的某些功能，它可能是委托给子类的好选择。子类仍然是主 ViewModel 的一部分，因此它只是减小 ViewModel 大小并简化这些线性操作的单元测试的一种方式。
【讨论】：