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

2019年8月3日 207次阅读

我有第一个使用MVC3的大型解决方案.我正在使用ViewModels,AutoMapper和DI.

要为一些更复杂的编辑/创建创建我的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

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

任何建议表示赞赏

最佳答案 您有一个正确的想法从存储库模式开始.根据您使用存储库的方式,我完全理解您最终会如何结束(甚至每个数据库表可能有1个).

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

业务层

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

服务层

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

这不是最具描述性的示例,但我希望它有助于提供重构选项的高级视图.

点赞