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

Question

我正在使用 MVC3 开发第一个大型解决方案。我正在使用 ViewModel、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)

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

---

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

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

我正在为汽车、租赁合同和租赁期创建一个存储库。所以当我认为应该只有一个时，这就是创建 3 个存储库。没有汽车，租用合同和期限就无法存在。因此，我以这种方式减少了一些存储库。

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

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

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

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

任何建议表示赞赏。

Answer 1

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

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

业务层

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

服务层

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

这不是最具描述性的示例，但我希望它对重构选项的高层次视图有所帮助。