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

61–70 of 92 posts

Re: The problem with dependency injection frameworks

#61

Post by giraffe_lady »

bsaul wrote: post #55
barrkel wrote: post #20

Earlier quoted context omitted.

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

Before « move fast and break things », there used to be a thing called « documentation ». It included things like « design documents » and would ensure people were able to quickly understand a piece of code.

Maybe, maybe there was. In my experience when someone talks about how much better "it" used to be and how low we've all sunk these days, "it" never really was as good as they're saying. But maybe.

In any case though I live and work now, when companies who prioritize and support the work of creating and maintaining thorough reliable documentation are rare. So I plan my work for situations I can expect to encounter now, not ones that may have been once.

Re: The problem with dependency injection frameworks

#64

Post by nitwit005 »

orobinson wrote: post #14

> 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

Some of them definitely go beyond "just code", in the sense that they actually change the normal behavior of the code. They intercept method calls, replace classes, etc. Spring is sort of famous for this: https://docs.spring.io/spring-framework/docs/3.0.0.M3/refere...

Re: The problem with dependency injection frameworks

#65

Post by hot_gril »

nitwit005 wrote: post #64
orobinson wrote: post #14

> 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 Some of them definitely go beyond "just code", in the sense that they actually change the normal behavior of the code. They intercept method calls, replace classes, etc. Spring is sort of famous for this: https://docs.spring.io/spring-framework/docs/3.0.0.M3/refere...

Or they use macros (e.g. in C++) to create something you can't reasonably read through.

Re: The problem with dependency injection frameworks

#66

Post by hot_gril »

We use this clunky C++ dep injection framework at my job that our most veteran SWEs swore never to use, but one day it became mandatory (lmao) for sorta unrelated reasons. The biggest issue is the initial learning curve; you don't gain much out of it for what you put in. It doesn't even catch bugs at compile time. Once you get it, you think of your code as having multiple main.cc's, and everything below that is regular code. So I think it's dumb, but it's not that big a deal.

When I write my own NodeJS backends, I just pass around a big object of all the global-ish deps like DB handles and thick clients. That works predictably and avoids the headaches you get meticulously plumbing everything through. So far I haven't felt any pain from this to push me to a DI framework.

There are far more important issues to consider in your system. If you're so concerned about globals, maybe you're making too big of a monolith service.

Re: The problem with dependency injection frameworks

#67

Post by hot_gril »

clumsysmurf wrote: post #34
twic wrote: post #16

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

Passing a single "context" struct/class/whatever into everything basically solves DI. I can see using a framework for this, but it doesn't seem necessary.

Re: The problem with dependency injection frameworks

#68

Post by naizarak »

Not sure why the author decides to single out DI frameworks as a problem. In most cases DI is just an implementation detail for how the framework serves up its abstraction layer over the underlying mechanisms. For example, Spring is built around injecting beans so it can wrap them in proxies which provide transaction managements, security, etc. Sounds like he's really just criticizing frameworks in general.

On the topic of DI, it's such a simple and common-sense design "pattern" that it shouldn't even have a buzzword label. All it means is that, given service A which uses service B, it's not service A's job to instantiate B and provide B with its required sub-dependencies (DataSource, config params, etc). A should only consume B without concerning itself as to how B was created in the first place. This is usually handled by some "container" service whose job is to build-up every other service and make them accessible to one another so they may be strict consumers without transitive dependencies.

Re: The problem with dependency injection frameworks

#69

Post by hot_gril »

_gabe_ wrote: post #21
oezi wrote: post #6

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

And this is how we end up with spaghetti code. Dependency management is a critical design decision . If you're polluting your global namespace with random classes that get injected everywhere, you end up with a massive tree of intertwined dependencies. Not relying on a DI framework forces you to see that god-awful mess of spaghetti and do something about it or live with the consequences. If you're not thinking about…

When you cross service boundaries, those globals get reset. I don't know how to say this exactly, but sometimes you're writing crappy code in a crappy language (Java), and nothing matters more than doing it quickly and integration-testing it. Worst case your code becomes such spaghetti that someone rewrites it, which is fine cause it's self-contained.
Post reply on HN