It always blew my mind that "dependency injection" is this big brouhaha and warrants making frameworks, when dynamic vars in Lisp basically accomplish the same task without any fanfare or glory.
> when you need a delayed job server to have the user context of different users depending who triggered the job
I feel this is just a facet of the same confusion that leads to creating beautiful declarative systems, which end up being used purely imperatively because it's the only way to use them to do something useful in the real world; or, the "config file format lifecycle" phenomenon, where config files naturally tend to become ugly, half-assed Turing-complete programming languages.
People design systems too simple and constrained for the job, then notice too late and have to hack around it, and then you get stuff like this.
For the standard web page lifecycle it's fine, but for instances like this it really does become fiddly.
But often it's possible, but often a ideological stance the framework team have taken that leads to a poor documentation issue.
The asp.net core team have some weird hills they die on, and some incredibly poor designs that stem from an over adherence to trendy patterns. It often feels they don't understand why those patterns exists.
This results in them hardly documentating how to use the DI outside of their 'ideal' flow.
They also try and push devs to use DI for injecting config. Which no other language does and is just unnecessarily complicated. And it's ended up with a system no-one really understands while the old System.Configuration, while clunky, at least automatically rebooted the app when you edited the config. Which is the 95% use case most devs would want.
FWIW, when I thought about it in the larger enterprise context, I realized that I also hold a seemingly opposite view. I presented that elsewhere in this thread:
TL;DR: the goal of enterprise frameworks isn't to make Perfect Software Framework or to make code beautiful, devoid of bloat, or even easy. Their goal is to make programming consistent and predictable, to make programmers exchangeable. It's to allow an average developer to churn around working results at a predictable pace, as long as the project is just standard stuff, and they don't bring their own opinions into it. Large businesses want things this way, because that's how they think about everything (see also: Seeing Like a State).
Of course, this doesn't mean the framework authors succeed at that goal either :). Some decisions are plain stupid. But less than one would think.
