|
|
|
|
|
|
by nulagrithom
3058 days ago
|
|
|
If you don't like DI then I feel like C# in general won't be your cup of tea. As for the "only for testing" bit, I disagree. I'm currently in a situation where I'm on the fence about two different ways to access my database (both are terrible options). Both db drivers are very different, and require very different code. However, they both return the same models. By defining an interface and injecting one service or the other in to my controllers, I can quite effectively and painlessly switch between the two. Why not a singleton? Because with one of the drivers it's better to build a new one on every request. Back to injecting configuration... I actually use this database access service across two different ASP.NET Core projects. The configuration manager has a nice way to extract only parts of the configuration in to a model. Combine with DI and I can easily split my configuration models between these projects without a shared config model. Sure, there's other ways to skin the cat. I'm not saying DI is the only way, but I do find it an effective method and certainly not a "nasty language hack". |
|
|
There's absolutely no reason you have to do DI in C#. C# only recently had native DI introduced.
The only reason to use DI is to be able to inject mocks. It's the only reason. Ruby, for example, can do this without DI. It's literally making bad code just to be able to test it.
It's a language bug that DI is needed.
There are some who believe DI somehow magically makes your code less coupled, but go take a look at any client project in the wild and that's immediately a laughable and indefensible position. If anything, DI makes it worse. I've seen classes with 20 odd service injected, which each all have their own 10 or 15 classes injected, making that class coupled to something like 70-100 other classes.
And DI makes it even harder to pick them apart.