The first time I saw DI in action, I was horrified and discouraged. It really broke my heart that that was what modern software had become. In this application, there were controller constructors with upwards of 40 arguments each -- tons of services being injected, many with very similar names (DocumentService, WebDocumentService, ExtendedDocumentService). The problem was very much in how the features were factored into services. But there was also a deeply irrational mania about this -- like people sincerely believed that having tons of services made your project "easy to maintain." So, this really soured my view of DI for a long time. There was a similar craze around interfaces and extracting an interface for every single class. There was a religious belief that this made your code "easy to maintain" because of the "D" in SOLID. ("D"epend on interfaces, not concrete classes.) The thing about this is there is a good case for DI, but you have to strip away the dogma and apply it smartly. And not every class or service needs and interface. Yes, it's a good idea to minimize biz logic in your controllers (for example) to assure testability. And when you get into testing, you'll find that -- yes -- you need to pay attention to what various classes depend on. Interfaces are a miracle when you have truly more than one implementation of a service, but they are just clutter (mental and physical) if you think they belong absolutely everywhere. So, today I see the benefit of DI, but I had to learn it in a cleansheet way and see the benefits on my own. The abusive implementation I had to deal with early on set me back a long time.