4 ms·
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 aft
by zo1 1y 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.
- orphea 1y ago> You can't just "go to definition" of the class being injected into yours, even if there is only one. Yes, I can? At least Rider can jump to the only implementation, no questions asked. > And no, it will not just point to your single implementation, it'll find the test implementation too. It will, but is it a problem to click the correct class from a list of two options?
- jen20 1y agoIf you only have one implementation, why do you even have an interface?
- rawling 1y agoSo I can mock it out for unit tests.
- jen20 1y agoThen you have two implementations…
- orphea 1y agoYou don't necessarily need to implement interfaces [in your code] to stub them in unit tests: var calculator = Substitute.For<ICalculator>();
- jen20 1y agoIf you’re doing that, you may as just mock your concrete class. Mockito supports this in Java. Perhaps this is needed in C#?
- wordofx 1y agoJava is virtual by default. C# is not. You could mark every single method virtual and mock it like Java. But it’s easier to define a contract and mock that.
- rawling 1y agoNot one that shows up when I hit "go to implementation".
- wordofx 1y agoLOL ok so you’ve never used C#
- Uvix 1y ago> You can't just "go to definition" of the class being injected into yours, even if there is only one. This situation isn't unique when using DI (although admittedly DI does make using interfaces more common). However, that's what the "go to implementation" menu option is for. For a console app, you're right that a DI framework adds a lot of complexity. But for a web app, you've already got all that framework code managing controller construction. If you've got the black box anyways, might as well embrace it.
- JADev62096 1y agoI'm glad someone knows how I feel. Yes, the comments about "$25 name for a 5c concept" ring true when you're looking at a toy example with constructor(logger) { .. }. Then you look at an enterprise app with 10 years of history, with tests requiring 30 mocks, using a custom DI framework that only 2 people understand, with multiple versions of the same service, and it feels like you've entered another world where it's straight up impossible to debug code.
- baobun 1y agoMake those dependency interfaces dynamic enough to be practically untyped, introduce arbitrary implicit ordering requirements, and we have now invented Middleware.