12

罗伯特·马丁说：“改变班级的理由不应该不止一个”。

让我们考虑绑定到视图的 ViewModel 类。ViewModel 有可能（甚至很可能）由彼此并不真正相关的属性组成。对于小视图，ViewModel 可能是相当一致的，但是当应用程序变得更加复杂时，ViewModel 会暴露数据，这些数据会因不同和不相关的原因而发生变化。

在 ViewModel 类的情况下，我们是否应该担心 SRP 原则？

4

4 回答 4

19

ViewModel 的唯一职责是为 View 提供它需要的信息。如果 View 需要不同且不相关的属性，这并不重要，因为 ViewModel 只有一个改变的原因，那就是 View 显示不同的属性。所以你不应该太担心。

也就是说，如果 ViewModel 确实变得很大，也许您可​​以考虑将视图分成几个子视图以提高可重用性并保持 View 和 ViewModel 的可管理性。

于 2009-02-28T00:44:33.457 回答
2

我同意 gcores。

一旦您看到 ViewModel 增长到超过两屏的文本，就该考虑将 ViewModel 拆分为多个子模型了。

另一个经验法则是，我在 XAML 文件中的嵌套级别永远不会超过两层——如果视图的一部分变得过于复杂，则该是视图重构的时候了——将内部 XAML 提取到单独的 UserControl 并创建相应的 ViewModel，这将是子视图的默认数据上下文。

于 2009-02-28T00:50:48.793 回答
0

是的，但这并不意味着糟糕的设计不能强迫你去做。

于 2009-02-27T23:52:06.407 回答
0

我同意将您的屏幕拆分为具有多个 ViewModel 的多个视图对于减少臃肿和复杂性是必要的。这是我用来帮助坚持使用 MVVM 的 SRP 的另一种模式：

这是一种情况。我的 ViewModel 需要获取数据并响应来自 UI 的过滤命令。我将 ViewModel 创建为复合结构。也就是说，有权访问 ViewModel 的私有成员的子类执行线性任务，例如处理过滤。我可能还有另一个子类，它执行基于标准选择项目的必要逻辑。你明白了。一旦 ViewModel 执行跨越多个方法的某些功能，它可能是委托给子类的好选择。子类仍然是主 ViewModel 的一部分，因此它只是减小 ViewModel 大小并使单元测试这些线性操作更容易的一种方式。

于 2010-03-22T13:47:39.943 回答