我有第一个大型解决方案，我正在使用MVC3。我正在使用ViewModels, AutoMapper和DI。
为一些更复杂的编辑/创建创建我的ViewModels，我注入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之外，上述所有内容都填充了select。
一般的想法和更新。Mark Seemann关于过度注射的博客文章鼓励我考虑这个问题。我对仓库特别感兴趣，为什么我必须注入这个数字。我认为考虑到我的设计，我显然没有为每个聚合根使用一个存储库(根据DDD)。
举个例子，我有汽车，汽车有租赁合同，租赁合同有租期。
我正在为汽车、租赁合同和租赁期限创建一个存储库。这是在创建3个存储库时我认为应该只有一个。没有汽车，租赁合同和期限就不存在。因此，我以这种方式减少了一些存储库。
我仍然有一些复杂的表单(客户需要这些大型表单)，它们需要控制器中的许多存储库。这可能是因为我重构得不够。据我所知，我将需要单独的存储库来获取选择列表。
我正在考虑创建某种服务的选项，以提供我需要的所有选择列表。这是好习惯/坏习惯吗?我的服务应该只面向聚合根吗?如果是这样，只有一个服务提供选择是错误的。然而，这些选择似乎是同一类型的东西，将它们组合在一起在某些方面是有吸引力的。
似乎我的问题类似于如何处理-constructor-over-injection-in-net
我想我现在更多地寻找关于选择列表服务是好是坏的具体建议。
欢迎指教
您从存储库模式开始的想法是正确的。根据您使用存储库的方式，我完全理解您最终可能会有很多(甚至每个数据库表1个)
您必须判断自己的规范和业务需求，但也许您可以考虑业务层或服务层。
业务层该层可能由业务对象组成，这些业务对象封装了视图模型(和固有视图)的一个或多个意图。您没有描述任何域，但是Users的业务对象可能包含一些CRUD方法。然后，您的视图模型将依赖于这些业务对象，而不是直接调用存储库方法。您可能已经猜到重构会将对存储库方法的调用移动到业务对象
服务层服务层甚至可以使用上面描述的一些业务对象，但也许你可以设计某种类型的消息传递协议/系统/标准来在你的web应用程序和服务器上运行的WCF服务之间进行通信，以控制某种状态。
这不是最具描述性的示例，但我希望它能帮助您从一个非常高的层次上了解重构选项。