[didibus]

> the reason for DI is to support the Dependency Inversion Principle : "High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

You can still depend on abstractions without DI. Just use an interface or asbtract class in your code.

DI only plays into how you acquire yourself an instance of the concrete class for that abstraction you depend on.

So it can be given to you by your caller (DI). You can go fetch it somewhere (ServiceLocator). You can create it through a utility (Factory). Or you can create it yourself old fashion way with new.

> But you don't have to use a library; many times I'm writing a simple-ish console app and just use good old "Poor Man's DI" where I manually construct my object graphs at startup

I will support that. I'd like people to be precise in their criticism, do you find the DI pattern troublesome, or some particular DI framework?

[chunkyfunky]

Neither, I'm a fully paid up and card-carrying DI-club member :)

I was kind of making the same point as you did, that you don't need to use any kind of DI library to achieve the DIP, but that in something like ASP.Net it is there and simple to use.