如何处理.NET 中的构造函数过度注入 [英] How to deal with constructor over-injection in .NET

问题描述

如果已经讨论过这个问题，我很抱歉，但我没有完全找到我想要的.我面临的问题更多是关于模式和设计选择，而不是关于 .NET 本身.我只是想听听您的建议，让我知道从哪里开始重构.

I'm sorry if that question was already discussed, but I didn't find exactely what I wanted. The problem I'm facing is more about patterns and design choices than about .NET itself. I just would like to have your advice to know where to start my refactorings.

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

Today I opend one of the classes in my actual application and found that it has 13 dependencies injected by constructor !!! In fact each developper added the dependecy it needed in method that he was writing.

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

One point of my understanding of DI is that when we inject a dependency by constructor it means that it's a mandatory dependency and should be used in all methods of the class. If we need a particular dependency just in one method of the given class, what does it mean for you ?

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

很难找到合适的平衡点.实际上，有时不可能以干净的方式封装行为.

What's difficult is to find the right balance. In reallity sometimes it's not possible to encapsulate the bahaviour in the clean way.

我正在考虑创建诸如服务聚合器之类的东西来隐藏其中一个背后的相关依赖关系，但如果您有其他建议，我会很乐意.提前致谢.

I was considering to create something like service aggregator to hind related dependency behind one of them but would like if you have other advices. Thanks in advance.

推荐答案

你是对的:如果你需要将 13 个依赖项注入到一个类中，这是你违反了单一责任原则.切换到属性注入没有帮助，因为它不会减少依赖项的数量 - 它只会暗示这些依赖项是可选的而不是强制性的.

You are correct: if you need to inject 13 dependencies into a class, it's a pretty sure sign that you are violating the Single Responsibility Principle. Switching to Property Injection will not help, as it will not decrease the number of dependencies - it will only imply that those dependencies are optional instead of mandatory.

基本上，有两种方法可以处理此类问题:

Basically, there are two ways to deal with this type of problem:

• 重构为 Facade 服务.这基本上是一个不间断重构，因为它维护了控制器的功能.但是，它将职责转变为协调/编排服务之间的交互，而不是管理实施的细节.
• 将班级拆分为独立的班级.如果每个服务都由不同的开发人员引入以支持方法的一个子集，则表明低内聚.在这种情况下，最好将类拆分为多个独立的类.

• Refactor to Facade Services. This is basically a non-breaking refactoring as it maintains the functionality of the Controller. However, it changes the responsibility toward coordinating/orchestrating the interaction between services instead of managing the nitty-gritty details of the implementation.
• Split up the class into independent classes. If each of the services were introduced by different developers to support a subset of the methods, it's a sign of low cohesion. In this case, it would be better to split up the class into several independent classes.

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

Specifically for ASP.NET MVC you may not want to split up an Controller because it will change your URL scheme. That's fair enough, but consider what this implies: it means that the single responsibility of the Controller should be to map URLs to application code. In other words, that's all a Controller should do, and it then follows that the correct solution is to refactor to Facade Services.

这篇关于如何处理.NET 中的构造函数过度注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！