[dkarl]

I think you're blurring some lines when you present a choice between using a DI framework, rolling your own framework, or not using "dependency injection as a pattern in general." "Dependency injection as a pattern in general" is unavoidable in complex software and undoubtedly a necessary thing in many contexts, whereas dependency injection frameworks are tools that are not necessary for using "dependency injection as a pattern."

My preferred approach to dependency injection is using the plain mechanisms of the language I'm using to pass dependencies as constructor and function parameters, without any framework.

I pass test fakes the same way. When doing things this way feels burdensome due to overly complex method signatures or overly complex initialization code, I look for ways to improve my design.

This works at every scale of code I've worked at. It's possible there's some size of project that it doesn't scale to, but for every project I've worked on where another engineer swore that dependency injection was absolutely necessary on the project, I've worked on a larger project where nobody ever suggested dependency injection and everything was fine.

My experience doesn't prove that dependency injection isn't necessary at some larger scale that I haven't experienced, of course, but it does convince me that the industry is rife with programmers who think they can't get by without it at scales where it is not only unnecessary but probably harmful.