top | item 44086437

(no title)

lemagedurage | 9 months ago

Another downside of DI is how it breaks code navigation in IDEs. Without DI, I can easily navigate from an instance to where it's constructed, but with DI this becomes detached. This variable implements Foo, but which implementation is it?

discuss

order

rightbyte|9 months ago

Ye debugability and grepability is terrible.

DI seems like some sort of job security by obscurity.

diggan|9 months ago

If your IDE starts to decide how you code and what kind of architecture/design you can use, I kind of feel like the IDE is becoming something more than just an IDE and probably you should try to find something else. But I mainly program in vim/nvim so maybe it's just par for the course with IDEs and I don't know what I'm talking about.

hx8|9 months ago

Are you not using an LSP with your text editor? If you are then you'll run into the same issue because it's the underlying technology. If you aren't using an LSP then you're probably leaving some workflow efficiency on the table.

surgical_fire|9 months ago

In IntelliJ at least this is a non-issue.

Kiro|9 months ago

How?

grugagag|9 months ago

This is what I hate most about DI as well and when I told some other devs about this pet peave of mine they were looking at me like I had 2 head or something.

wiseowise|9 months ago

Which language? Android Studio, for example, allows you to navigate to Hilt injection points.

wordofx|9 months ago

Not an issue in C#

zo1|9 months ago

Definitely still an issue in C#. C# devs are just comfortable with the way it is because they don't know better and are held hostage. Everything in C# world after a certain size will involve IOC/DI and the entire ecosystem of frameworks that has co-evolved with it.

The issues are still there. You can't just "go to definition" of the class being injected into yours, even if there is only one. You get the Interface you expect (because hey you have to depend on Interfaces because of something something unit-testing), and then see what implements that interface. And no, it will not just point to your single implementation, it'll find the test implementation too.

But where that "thing" gets instantiated is still a mystery and depends on config-file configured life-cycles, the bootstrapping of your application, whether the dependency gets loaded from a DLL, etc. It's black-box elephants all the way to the start of your application. And all that you see at the start is something vague like: var myApp = MyDIFramework.getInstance(MyAppClass); Your constructors, and where they get called from is in a never-ending abyss of thick and unreadable framework code that is miles away from your actual app. Sacrificed at the alter of job-creation, unit-testing and evangelist's talk-resume padding.

rootsofallevil|9 months ago

I haven't really done any c# for 5+ years. What has changed?

I remember trying to effectively reverse-engineer a codebase (code available but nobody knew how it worked) with a lot of DI and it was fairly painful.

Maybe it was possible back then and I just didn't know how ¯\_(ツ)_/¯

asp_hornet|9 months ago

C# code bases are all about ruining code navigation with autofac and mediatr