asp.net-mvc-3 – 是否有可能将太多的存储库注入控制器？

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

我已经看到它提到注入大量的repositiories是不好的做法,我应该重构.对很多人来说有多少？这对很多人来说？我该怎么重构？我应该创建一个返回选择列表等的专用服务吗？

这里给出一个例子就是我的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)

以上所有内容都填充了除了requireRepository和providecontractRepository之外的选项,我用它来获取需求和提供.

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

我有汽车,汽车有租赁合同,租用合同有租期.

我正在为汽车,租用合同和租用期创建一个存储库.所以当我认为应该只有一个时,就创建了3个存储库.如果没有汽车,租赁合同和期限就不存在.因此,我已经减少了一些存储库.

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

我正在考虑创建某种服务的选项,它将提供我需要的所有选择列表.这是好习惯/不良做法吗？我的服务应该只围绕聚合根源吗？如果是这样,有一个服务提供选择将是错误的.然而,选择似乎是相同类型的东西,并将它们组合在一起在某些方面是有吸引力的.

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

我想我现在更关注选择列表服务是好还是坏的具体建议.

任何建议表示赞赏