This guy's at Dependency Injection revelations Stage 2.
In Stage 1 he realised that a bad understanding of DI has resulted in a ton of pointless Interfaces.
At Stage 2 he realised he didn't need those interfaces to unit test.
Wait until he reaches stage 3 realises that DI itself is fairly pointless and bad coders are still going to make a massively coupled mess even if you force them to use DI.
For example, one of our controllers has 20 odd "services" injected, with each of those services then having a bunch of other services/Dals/etc. injected, causing a massively coupled dependencies. So much for DI cleaning your code.
DI code is no less coupled than if you just coded it cleanly in the first place.
The only good thing I've found it for in C# is that it passes the EF context around per request without you having to manage that, so all your services are using the same context.
In Stage 1 he realised that a bad understanding of DI has resulted in a ton of pointless Interfaces.
At Stage 2 he realised he didn't need those interfaces to unit test.
Wait until he reaches stage 3 realises that DI itself is fairly pointless and bad coders are still going to make a massively coupled mess even if you force them to use DI.
For example, one of our controllers has 20 odd "services" injected, with each of those services then having a bunch of other services/Dals/etc. injected, causing a massively coupled dependencies. So much for DI cleaning your code.
DI code is no less coupled than if you just coded it cleanly in the first place.
The only good thing I've found it for in C# is that it passes the EF context around per request without you having to manage that, so all your services are using the same context.