Why would you want Dependency Injection without configuration?

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 don't think you want a DI-framework without configuration. I think you want a DI-framework with the configuration you need.

I'll take spring as an example. Back in the "old days" we used to put everything in XML files to make everything configurable.

When switching to fully annotated regime you basically define which component roles yor application contains. So a given service may for instance have one implementation which is for "regular runtime" where there is another implementation that belongs in the "Stubbed" version of the application. Furthermore, when wiring for integration tests you may be using a third implementation.

When looking at the problem this way you quickly realize that most applications only contain a very limited set of component roles in the runtime - these are the things that actually cause different versions of a component to be used. And usually a given implementation of a component is always bound to this role; it is really the reason-of-existence of that implementation.

So if you let the "configuration" simply specify which component roles you require, you can get away without much more configuration at all. Of course, there's always going to be exceptions, but then you just handle the exceptions instead.

Answer 2

I'm on a path with krosenvold, here, only with less text: Within most applications, you have a exactly one implementation per required "service". We simply don't write applications where each object needs 10 or more implementations of each service. So it would make sense to have a simple way say "this is the default implementation, 99% of all objects using this service will be happy with it".

In tests, you usually use a specific mockup, so no need for any config there either (since you do the wiring manually).

This is what convention-over-configuration is all about. Most of the time, the configuration is simply a dump repeating of something that the DI framework should know already :)

In my apps, I use the class object as the key to look up implementations and the "key" happens to be the default implementation. If my DI framework can't find an override in the config, it will just try to instantiate the key. With over 1000 "services", I need four overrides. That would be a lot of useless XML to write.