Never ceases to amaze me how much passion calling a constructor can evoke.
I have never, ever, been in a situation where calling constructors was simplified by adding a DI framework.
The problem with dependency injection frameworks
31–40 of 92 posts
Re: The problem with dependency injection frameworks
#32> “This implementation is difficult to unit test.” Horsepucky. You can still have dependency injection without a framework. Just make a constructor that takes the dependency as an optional parameter. Done. Applause. Early lunch. Ok so it's specifically the frameworks that's disliked. > Furthermore, dependency injection frameworks encourage you to think in terms of globals. That’s what they inject! A single, globally-…
Try Dagger, it generates DI code during build. So it's kinda hard code, but the framework does it for you. So the startup is much faster, and easier for JIT compiler to reason (no reflection)
Re: The problem with dependency injection frameworks
#33> I need to know everything that’s going on in my code. I need simple, straightforward function calls. Nothing else! I want to be able to start at main() and trace through the code. I want to look at callers and find where every parameter came from. Reading code is hard enough already. Magic frameworks make it harder. But these frameworks aren't magic. They're just code. Sure it means you have a bit more code to read…
>But these frameworks aren't magic. They're just code. "Magic" in framework parlance doesnt mean hocus pocus. It just means concealed abstraction.
Yes I’m aware. My point was it’s not that concealed once you’ve invested the time to read the docs and peek at the code of whatever framework you’re using. The time to do that is nothing compared to the time saved using these frameworks.
I wasn’t sitting there thinking Harry Potter wrote Spring Boot.
Re: The problem with dependency injection frameworks
#34I gave up on dependency injection frameworks a while ago. Now there's just some "wiring" code somewhere that wires up the components. It's small (one statement per component), trivial to write, easy to understand, and makes any kind of customisation easy (disabling whole subsystems under config, having alternative implementations for subsystems, etc), because it's just code. It's also testable! The setup code is fact…
> I think anyone arguing for frameworks should spend some time making a serious attempt at frameworkless dependency injection. The frameworks are really doing so little for you, at occasionally horrendous cost.
That is what I did, and decided a DI framework was much better. If you have a single scope, like singletons, its pretty easy to do the wiring manually. If not, then you see very quickly that your scope management code and rewiring of same things at different layer quickly becomes tedious, error prone (becoming out of sync with another wiring), boilerplate.
Re: The problem with dependency injection frameworks
#35I advise to try build-time DI frameworks, like Dagger, see how it generates the glue code, and then ditch it and write the same glue code yourself.
Yes, build-time cannot do tricky cases (when it depends on some runtime-only thing), but I'm yet to see any case of that.
Build-time is also easier on JIT compiler, as there's no reflection involved in runtime, for VM it's all just hardcoded.
Re: The problem with dependency injection frameworks
#36I agreed, until I tried FastApi. DI can be done right.
Re: The problem with dependency injection frameworks
#37Does he have a specific framework in mind?
Because most of the problems he lists do not exist in Symfony AFAIK, for example.
Re: The problem with dependency injection frameworks
#38Never ceases to amaze me how much passion calling a constructor can evoke. I have never, ever, been in a situation where calling constructors was simplified by adding a DI framework.
Until you want to add an argument to that constructor and find yourself modifying lots of files just to update that call everywhere.
Or need a value from the application config, and have to patch the configuration instance through, several levels of classes deep. After wasting a day or two with those shenanigans, you’ll gladly take the DI framework, which makes both scenarios a single-line, 10 second change.
Re: The problem with dependency injection frameworks
#39This is how I cope with Java DI.
I write my classes with one constructor that takes anything I need as final private members.
This has the benefit of working with any DI framework without any annotations or other hacks.
It also has the benefit of being usable or callable without using a DI framework.
Re: The problem with dependency injection frameworks
#40Never ceases to amaze me how much passion calling a constructor can evoke. I have never, ever, been in a situation where calling constructors was simplified by adding a DI framework.
Until you want to add an argument to that constructor and find yourself modifying lots of files just to update that call everywhere. Or need a value from the application config, and have to patch the configuration instance through, several levels of classes deep. After wasting a day or two with those shenanigans, you’ll gladly take the DI framework, which makes both scenarios a single-line, 10 second change.
Or just create two versions of the constructor - one that takes the arg, and one that doesn't.
The one that doesn't does whatever magic you were planning for the DI, does that, then calls the constructor with the arg.