Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The problem with dependency injection frameworks

jamesshore.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: The problem with dependency injection frameworks

#11

Post by Traubenfuchs »

karmakaze wrote: post #7

> “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-…

In spring, you can have multiple beans (=DI object instances) of the exact same class/interface. You can define one as primary and have to give them different names.

You can also automate bean creation per thread, per request, per session or whatever else floats your boat. Instance/bean persistence is easy too, if you really want to go that far (you should not).

For regulatory reasons, I once even had to implement a datasource selector for spring, that would pick the database connection based on userId.

Why do people that have zero idea about what they are writing find so much attention on hacker news?

Re: The problem with dependency injection frameworks

#12

Post by rektide »

justesjc wrote: post #8
oezi wrote: post #6

Hard disagree. Spending design time on dependency management is time not spend on more import design decisions.

Are you evaluating the points made by James from your context and limiting your understanding? If you work for a company where software is not a differentiator, but a cost to doing business, then using frameworks, DI or not, is probably the right thing to do. But if your code is a core part of the business, you probably don't want to give control to some third party that may screw you. All successful companies that I…

What major upheaval examples should we fear? DI frameworks seem quite reloable, trustworthy, & consistent. I cant think of any examples of a community being burned by trusting their framework. I cant think of any cases or blogs where someone has been left up a creek, has ended up hard clashing with their framework

I dont see what justifies this fear, uncertainty, and doubt.

Re: The problem with dependency injection frameworks

#13

Post by mrbungie »

travisgriggs wrote: post #9

> Every line of code in your system adds to your maintenance burden, and third-party code adds more to your maintenance burden than well-designed and tested2 code your company builds itself. Every SAAS vendor and framework advocate should have to put this on their product in black letters in a white background. Same typography as “Smoking is addictive…”

Yeah, good idea, but company architects should make a similar advice about NIH though.

A dependency is a dependency, there may be tradeoffs between using third-party software and developing new in-house code, but using "Invented here" code does not vanish any kind of complexity away, it just manages it differently.

Re: The problem with dependency injection frameworks

#14

Post by orobinson »

> 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 through to work out what's causing a problem but it's still just code. The time cost of potentially more difficult debugging when things go wrong is nothing compared to the time saved not having to wire things together manually.

I also find DI frameworks actually encourage good design by making it easier to write small, single purpose classes. You don't need to spend time working out where to initialise them so they can be passed to all the dependent classes.

Re: The problem with dependency injection frameworks

#15

Post by twic »

karmakaze wrote: post #7

> “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-…

The first dependency injection framework i learned was Nucleus [1]. An unusual feature of Nucleus is that it has no type-based autowiring. You write a little properties file for every component, and to inject a component into another, the recipient uses the path to the other component's properties file. It is shockingly basic, but it works really well. Everything is explicit, but simple enough that it's not laborious to use. Having multiple instances of components is trivial, because they're just separate properties files. Indeed, the driving use case for Nucleus, the ATG commerce framework (since bought by Oracle) had multiple instances of many classes (eg the generic ORM repository class, for different siloes of data). I was really surprised when i first used an autowiring dependency injection framework, where this is either impossible, or you have to jump through hoops to do it.

[1] https://docs.oracle.com/cd/E41069_01/Platform.11-0/ATGPlatfo...

Re: The problem with dependency injection frameworks

#16

Post by twic »

I 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 factored in such a way that it's harmless to run (eg sockets aren't opened during wiring), and it does all the config parsing and resolution and so on. So i have a suite of tests which run it, and then do some trivial checks like "all the necessary config is available", "handlers are defined for all the market data we subscribe to", etc. They've caught a bunch of schoolboy errors which would otherwise only have been found in staging.

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.

Re: The problem with dependency injection frameworks

#17

Post by jupp0r »

I like explicitly listing dependencies (as interfaces, as you shouldn't depend on abstractions). Golang's context are also a nice pattern for bundling them opaquely based on scope if you just need to pass them through (for logging, tracing and other ubiquitous purposes).

Re: The problem with dependency injection frameworks

#18

Post by travisgriggs »

mrbungie wrote: post #13
travisgriggs wrote: post #9

> Every line of code in your system adds to your maintenance burden, and third-party code adds more to your maintenance burden than well-designed and tested2 code your company builds itself. Every SAAS vendor and framework advocate should have to put this on their product in black letters in a white background. Same typography as “Smoking is addictive…”

Yeah, good idea, but company architects should make a similar advice about NIH though. A dependency is a dependency, there may be tradeoffs between using third-party software and developing new in-house code, but using "Invented here" code does not vanish any kind of complexity away, it just manages it differently.

Agreed. That’s why I thought the footnote in the quote was brilliant. Guess I should’ve included that part as well:

> [2] Ay, there’s the rub. I’m assuming competence. (If your company isn’t competent, well, you know what you need to do.)

Re: The problem with dependency injection frameworks

#19

Post by nomercy400 »

The magic happens at so many levels. Apparently a third-party DI framework is too much magic, but the third-party compiler is not, nor is the out-of-order, speculating third-party CPU.

A DI framework is just another level of magic, which once you accept/embrace it and play by its rules (like using a compiler), makes developing other code easier.

Re: The problem with dependency injection frameworks

#20

Post by barrkel »

travisgriggs wrote: post #9

> Every line of code in your system adds to your maintenance burden, and third-party code adds more to your maintenance burden than well-designed and tested2 code your company builds itself. Every SAAS vendor and framework advocate should have to put this on their product in black letters in a white background. Same typography as “Smoking is addictive…”

In a company, code you write yourself is a dead end. You want as little of it as possible.

Staff turn over. What was a first party piece of code well understood within the company inevitably turns into a poorly documented piece of code written by a third party no longer employed, and there is no community of users to help out with problems.

Write and own code which is fundamental to the business model's value proposition, the code which delivers product market fit. Eliminate other code where possible. Upstream or open source improvements that aren't part of the competitive edge.

There are exceptions of course, for trivial functionality whose fully loaded cost of integration and upkeep as a third party is higher than home grown, but it's not a lot.

The other alternative is to be such an awesome company that nobody who contributes a lot quits.

Post reply on HN