我有第一个使用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)
上面的所有内容都填充了除了requireRepository和providecontractRepository之外的选项，我用它来获取需求和优惠。
更新 一般的想法和更新。 Mark Seemann关于过度注射的博客文章鼓励我考虑这个问题。我特别感兴趣的是存储库以及我为什么要注入这个数字。我认为考虑过我的设计后我显然没有为每个聚合根使用一个存储库（根据DDD）。
我有汽车，汽车有租赁合同，租用合同有租期。
我正在为汽车，租用合同和租用期创建一个存储库。所以当我认为应该只有一个时，就创建了3个存储库。如果没有汽车，租赁合同和期限就不存在。因此，我已经减少了一些存储库。
我仍然需要一些复杂的表单（客户要求这些大型表单），这些表单需要控制器中的许多存储库。这可能是因为我没有足够的重构。据我所知，虽然我需要单独的存储库来获取选择列表。
我正在考虑创建某种服务的选项，它将提供我需要的所有选择列表。这是好习惯/不良做法吗？我的服务应该只围绕聚合根源吗？如果是这样，有一个服务提供选择将是错误的。然而，选择似乎是相同类型的东西，并将它们组合在一起在某些方面是有吸引力的。
看起来我的问题类似于how-to-deal-with-constructor-over-injection-in-net
我想我现在更关注选择列表服务是好还是坏的具体建议。
任何建议表示赞赏。
答案 0 :(得分：2)
您有正确的想法从存储库模式开始。根据您使用存储库的方式，我完全理解您最终会如何结束（甚至每个数据库表可能有1个。）
您必须判断自己的规范和业务要求，但也许您可以考虑业务层或服务层。
此图层可能由业务对象组成，这些业务对象封装了视图模型的一个或多个意图（以及固有的视图。）您没有描述任何域，但可能是用户的业务对象可能包括一些CRUD方法。然后，您的视图模型将依赖于这些业务对象，而不是直接调用存储库方法。您可能已经猜到重构会将对存储库方法的调用转移到业务对象
中服务层甚至可能使用上面描述的某些业务对象，但也许您可以设计某种类型的消息传递协议/系统/标准，以便在您的Web应用程序和服务器上运行的WCF服务之间进行通信，以控制某种。
这不是最具描述性的示例，但我希望它有助于提供重构选项的高级视图。