Why would you want Dependency Injection without co

Question

After reading the nice answers in this question, I watched the screencasts by Justin Etheredge. It all seems very nice, with a minimum of setup you get DI right from your code.

Now the question that creeps up to me is: why would you want to use a DI framework that doesn't use configuration files? Isn't that the whole point of using a DI infrastructure so that you can alter the behaviour (the "strategy", so to speak) after building/releasing/whatever the code?

Can anyone give me a good use case that validates using a non-configured DI like Ninject?

Answer 1

I received this comment on my blog, from Nate Kohari:

Glad you're considering using Ninject! Ninject takes the stance that the configuration of your DI framework is actually part of your application, and shouldn't be publicly configurable. If you want certain bindings to be configurable, you can easily make your Ninject modules read your app.config. Having your bindings in code saves you from the verbosity of XML, and gives you type-safety, refactorability, and intellisense.

Answer 2

If you want to change the behavior after a release build, then you will need a DI framework that supports external configurations, yes.

But I can think of other scenarios in which this configuration isn't necessary: for example control the injection of the components in your business logic. Or use a DI framework to make unit testing easier.

Answer 3

You should read about PRISM in .NET (it's best practices to do composite applications in .NET). In these best practices each module "Expose" their implementation type inside a shared container. This way each module has clear responsabilities over "who provide the implementation for this interface". I think it will be clear enough when you will understand how PRISM work.