当使用 DI 和构造函数注入(inject)时，对于违反 SRP 的情况有一个有用的指标，因为构造函数的参数数量会增加到我们开始感到不安的数量。解决这个问题的方法是重构为合理定制的类，并使用外观服务和类似方法。
但是，当谈到 MVVM，尤其是 View 模型时，我很难应用这些规则。 View 模型本质上负责提供命令，这些命令在调用时执行一些 UI 逻辑并调用业务层。我不想开始讨论业务逻辑的放置位置，让我们商定它在单独的类中。
现在想象一个简单的场景:我们有一个包含文件列表的窗口。用户可以添加文件、删除文件以及对它们执行一些操作，例如重命名和打开包含的文件夹。该窗口还异步收集和显示列表列中文件的一些元数据。此外，用户可以打开详细信息 View 并触发在线帮助。所有这些都可以通过工具栏和上下文菜单完成。好的，让我们到此为止。集群功能的一种直接方法可能是:
- ViewModel(对于整个窗口，为 提到的功能)
View 模型的依赖:
- 文件操作
- WindowsExplorerService(打开资源管理器窗口 显示包含的文件夹)
- 在线帮助
- 元数据收集器
- MessageService(打开消息框以显示错误和 喜欢)
- DetailsService(提供 UI 以显示已知的详细信息 文件格式)
这已经是 6 个依赖项，通过添加可以从工具栏触发的功能可以很容易地增加这个数字。在我看来，依赖项不能隐藏在合理的外观服务背后，因为它们中的每一个都涵盖了完全不同的功能领域(好吧，我们可以争论 MetadataGatherer 和 FileManipulation)。
我认为 View 模型的特殊之处在于它们将用户操作的转发封装到非常不同的依赖项中。 然而，6 个或更多的依赖项让我感到不安，并且各自的构造函数闻起来很糟糕。我错过了重要的一点吗？关于如何重构这样的一般情况的任何想法？
最佳答案
这里的解决方案是使用组合。主窗口需要是元素的组合，每个元素都有自己的 View 模型，并且该 View 模型将处理单一职责。主视图模型将编排它们。他们可以使用事件总线相互通信。几乎所有流行的 MVVM 框架(我知道 Caliburn Micro 和 ReactiveUI)都支持这一点。
关于c# - MVVM 中的依赖注入(inject)和单一职责原则，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44613066/