是否可以向控制器注入太多存储库？

Question

我正在使用 MVC3 开发第一个大型解决方案。我正在使用 ViewModels、AutoMapper 和 DI。

为了为一些更复杂的编辑/创建创建 ViewModel，我注入了 10 个左右
存储库。对于除其中一个存储库之外的所有存储库，它们仅用于获取数据以填充 ViewModel 上的选择列表，因为我只是获取关联的 FK 实体等。

我已经看到它提到注入大量存储库是不好的做法，我应该重构。多少等于多少？这对很多人来说都是这样吗？我应该如何重构？我应该创建一个返回选择列表等的专用服务吗？

这里仅举一个例子，这是我的RequirementsAndOffer控制器的构造函数，

       public RequirementsAndOfferController(
IdefaultnoteRepository defaultnoteRepository, 
IcontractformsRepository contractformsRepository, 
IperiodRepository periodRepository, 
IworkscopeRepository workscopeRepository, 
IcontactRepository contactRepository, 
IlocationRepository locationRepository, 
IrequirementRepository requirementRepository, 
IContractorRepository contractRepository, 
IcompanyRepository companyRepository, 
IcontractRepository contractRepository, 
IrequirementcontracttypeRepository requirementcontracttypeRepository, 
IoffercontractRepository offercontractRepository)

除了我用来获取需求和报价的requirementRepository和offercontractRepository之外，上述所有内容都填充了选择。

---

更新 一般想法和更新。 Mark Seemann 关于过度注入的博客文章鼓励我考虑这个问题。我特别对存储库以及为什么我必须注入这个数字感兴趣。我认为考虑到我的设计后，我显然没有为每个聚合根使用一个存储库（根据 DDD）。

例如，我有汽车，汽车有租赁合同，租赁合同有租赁期。

我正在创建一个汽车、租赁合同和租赁期的存储库。因此，当我认为应该只创建一个存储库时，却创建了 3 个存储库。没有汽车就不可能存在租赁合同和期限。因此我通过这种方式减少了一些存储库。

我仍然留下一些复杂的表单（客户需要这些大型表单），它们需要控制器中的多个存储库。这可能是因为我重构得还不够。据我所知，我将需要单独的存储库来获取选择列表。

我正在考虑创建某种服务的选项，该服务将提供我需要的所有选择列表。这是好的做法还是坏的做法？我的服务应该只围绕聚合根吗？如果是这样，只有一项服务提供选择将是错误的。然而，这些选择似乎确实是同一类型的东西，并且将它们组合在一起在某些方面很有吸引力。

看来我的问题类似于 how-to-deal-with -constructor-over-injection-in-net

我想我现在更多地寻找关于选择列表服务是好还是坏的具体建议。

任何建议表示赞赏。

Answer 1

从存储库模式开始，您就有了正确的想法。根据您使用存储库的方式，我完全理解您最终可能会得到很多（甚至可能每个数据库表 1 个）。

您必须判断自己的规范和业务需求，但也许您可以考虑业务层或服务层。

业务层

这一层可能由封装视图模型（以及固有视图）的一个或多个意图的业务对象组成。您没有描述您的任何域，但可能是用户的业务对象可以包括一些 CRUD 方法。然后，您的视图模型将依赖于这些业务对象，而不是直接调用存储库方法。您可能已经猜到重构会将对存储库方法的调用移至业务对象中

服务层

服务层甚至可能使用上面描述的某些业务对象，但也许您可以设计某种类型的消息传递协议/系统/标准来在服务层之间进行通信您的 Web 应用程序以及可能在服务器上运行的 WCF 服务来控制某种状态。

这不是最具描述性的示例，但我希望它有助于对重构选项有一个非常高层次的了解。