如何在.NET中处理构造函数的过度注入

Question

如果这个问题已经讨论过,我很抱歉,但我并没有真正找到我想要的东西.我面临的问题更多是关于模式和设计选择而不是.NET本身.我想建议你知道从哪里开始我的重构.

今天我在我的实际应用程序中打开了一个类,发现它有13个由构造函数注入的依赖项!实际上,每个开发人员都在他正在编写的方法中添加了所需的依赖性.

我对DI的理解之一是,当我们通过构造函数注入依赖项时,它意味着它是一个强制依赖项,应该在类的所有方法中使用.如果我们只需要给定类的一个方法中的特定依赖项,它对您意味着什么？

• 给定的课程做得太多了？我应该考虑创建一个只需要依赖的新类型？
• 我应该按财产注入？但在那个特定的方法中,依赖是强制性的,所以我认为这不是一个好的选择.
• 我应该通过方法注入？

找到合适的平衡点很困难.实际上,有时候不可能以干净的方式封装bahaviour.

我正在考虑创建像服务聚合器这样的东西来隐藏其中一个相关的依赖关系,但是如果你有其他建议的话.提前致谢.

Answer 1

你是对的:如果你需要在一个类中注入13个依赖项,那么这是一个非常明确的信号,表明你违反了单一责任原则.切换到Property Injection无济于事,因为它不会减少依赖项的数量 - 它只会暗示这些依赖项是可选的而不是强制的.

基本上,有两种方法可以解决这类问题:

• 重构立面服务.这基本上是一个不间断的重构,因为它维护了Controller的功能.但是,它改变了协调/协调服务之间交互的责任,而不是管理实现的细节.
• 将班级分成独立的班级.如果每个服务由不同的开发人员引入以支持方法的子集,那么这是低内聚的标志.在这种情况下,最好将类拆分为几个独立的类.

特别是对于ASP.NET MVC,您可能不希望拆分Controller,因为它会更改您的URL方案.这是公平的,但请考虑这意味着什么:它意味着Controller 的唯一责任应该是将URL映射到应用程序代码.换句话说,这就是Controller应该做的所有事情,然后正确的解决方案就是重构Facade Services.

Answer 2

仅仅因为依赖是强制性的并不意味着它应该在类的所有方法IMO中使用.它应该在逻辑上是类本身配置的一部分.

另一方面,如果一个类有13个依赖项,那么它可能做得太多了.这些依赖项中的任何一个在逻辑上属于一起吗？也许依赖本身应该是"更大的" - 或者很可能你的班级应该做得更少.

Answer 3

这听起来像是一个类有太多依赖的情况，即它是一个上帝类。尝试将其分解为更离散的职责。