How to deal with constructor over-injection in .NET

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

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.

Leave a Comment