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

问题描述

对不起，如果这个问题已经讨论了，但是我没有找到我想要的东西。我所面临的问题更多是关于.NET本身的模式和设计选择。我只想要你的建议来知道在哪里开始重构。

今天我在实际的应用程序中启动了一个类，发现它有13个依赖注入通过构造函数!!!事实上，每个开发人员都添加了他正在撰写的方法中需要的依赖。

我对DI的了解的一点是，当我们通过构造函数注入依赖关系时，这意味着它是一个强制依赖关系，应该在类的所有方法中使用。如果我们需要一个给定类的一个方法中的一个特定的依赖关系，那么对你来说意味着什么？

• 给定的类太多了？我应该考虑创建一个只需要依赖的新类型？


• 我应该注入财产？但是在这种特定方法中，依赖是强制性的，所以我不认为这是一个不错的选择。


• 我应该通过方法注入

难以找到正确的平衡。有时候不可能以干净的方式封装bahaviour。

我正在考虑创建一些像服务聚合器这样的后台相关依赖关系，但是会喜欢如果你有其他建议。感谢提前。

解决方案

你是正确的：如果你需要注入13个依赖关系到一个类，这是一个很明确的迹象您违反单一责任原则。 切换到属性注入将无法帮助，因为它不会减少依赖关系的数字 - 这只会暗示这些依赖关系是可选的，而不是强制性的。

基本上，有两种方法来处理这种类型的问题：

• 重组以汇总服务。这基本上是一个不间断的重构，因为它维护了Controller的功能。但是，它将责任改变为协调/协调服务之间的交互，而不是管理实施细节。


• 将课分成独立课。如果每个服务都由不同的开发人员引入以支持方法的一个子集，那么这是一个低凝聚力的标志。在这种情况下，最好将类分成几个独立的类。

对于ASP.NET MVC而言，您可能不会想分割一个控制器，因为它会改变你的URL方案。这是足够公平的，但请考虑这是什么意思：这意味着Controller的单一责任应该是将URL映射到应用程序代码。换句话说，这就是Controller应该做的一切，然后，正确的解决方案是将重构到汇总服务。

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.

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.

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 ?

• The given class does too much ? I should consider to create a new type just with a needed dependency ?
• I should inject by property ? But in that particular method a dependency is mandatory so I don't think it's a good choice.
• I should inject by method ?

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.

解决方案

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:

• Refactor to aggregate 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.

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 aggregate services.

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