It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

Well do you really need to mock everything? And if so, how is that different than any other stack?

Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.

I once "inherited" a project where I counted more than thirty levels between the web pages and the send/receive on a queue to the system that actually did the work.

Funnily enough they had a huge team (and over 30 thousand classes) and a lot of time (over two years) but they couldn't finish it.

Edit: Should have said it was J2EE rather than .Net

I agree. I've spent the past 6-9 months cleaning up a .NET MVC project and one of the first things I did was to rip out all interfaces that weren't being used the way I expect interfaces to be used.

We have the base MVC project that references services for DI. We load in another DLL via Ninject to add customization on top of those services (custom parsing of some magnetic card swipes for different institutions we deploy to and such). I discovered that while all of our services (~20) had an interface, only one of them was being customized/overridden. This mean that in order to do something as simple as a parameter change, it had to be changed in way too many places: the definition, the implementation, and the usages.

Why have that extra layer? If we need to override in the future, we can add more interfaces. For now, I just want to maintain my sanity.

I am seeing it all the time when consulting for companies. Their developers just love taking relatively small things and turning it into multilayered monster with insane amount of dependencies for code, development building pipelines and deployment.

I see that too - but I also see plenty of completely un-testable code, because the controller constantly reads from AppSettings, or creates a new database connection directly, or similar issues.

For small applications, instead of going full on DI, I sometimes just make a few simple public static properties, that I initialize on program startup. Then you can initialize them differently in your test harness. This is a lot easier to understand if you're not an expert in the chosen DI framework or app framework.

I am designing financial software for the crypto industry and I definitely prefer the ability to 1) have a high test coverage, and 2) quickly be able to write regression tests. Without dependency injection with mockable objects, that would not be possible.

Probably not but it is in my opinion very nice to have the ability to mock evertyhing if and when you need it.

You always have the ability. It's just writing code. But you should only do it when you need to.

You can mock classes with virtual methods/properties.

I prefer making interfaces instead, though. I find it useful to make the boundaries between components explicit.

I'm pretty sure you could do this via reflection and virtual public methods. The same way entity framework creates its proxy classes.

Which strategy? If your dependencies are all interfaces, then they're all mockable.