Simplicity:
It seems Jacob is under the misguided notion that DI makes software MORE complex. I have architected 5 commercial projects using DI spanning various domains, and I have found the opposite to be true. If I’m writing a service and find that it needs a new dependency, I simply add a property and start using it. Consider what this means; the entirety of a service’s dependency code is a single property declaration statement. No simpler design can be imagined.

Separation of Concerns:
DI separates and modularizes the concern of application object construction and wiring. This concern would otherwise be scattered throughout the code; not good. This is similar to the way AOP modularizes cross-cutting concerns. A large DI method or DI XML definition file might initially seem complex, but it’s all the same stuff: construction and wiring, i.e., it is highly cohesive. Those that use DI undoubtedly find it liberating to no longer have to worry about dependency management, as it’s all done in one place in one way. Thus, we are left to focus unfettered on our business problems.

Loose Coupling:
DI does not directly make code more loosely coupled, but it makes substantially easier practices that do, e.g., developing to interfaces.

Transparency:
The argument that DI breaks encapsulation is erroneous. Encapsulation refers to the hiding of design decisions that don’t need to be known to outsiders. If we’re operating at the level of a class, we NEED TO KNOW the types it depends on. DI makes these dependencies explicit and transparent. If the goal is encapsulation on a larger scope, one should look to technologies like OSGi.

Not only does DI deliver on all of these, but I would argue that on average it does so in fewer lines of code. So, the question is: Why wouldn’t you use DI on every project?

Great write up and I think you have a good handle on the value of DI.

I think a great example is how Windsor can also control the lifecycle of your components. Additionally, Windsor as an IoC brings in other aspects, such as EventWiring, AoP interceptors, etc…

What this means Jacob is that the lightweight container can do more than just ‘create’ your objects.

Take a typical Pub - Sub. With an IoC, you can register your publisher and subscriber’s in the configuration. If you need to add a new one, or remove one. You edit a config file.

Windsor can create and objects, start up the publisher, and help facilitate the event handling.

If you have ever done deployment releases of code or worked on a team, these type of code changes can introduce bugs, etc…

There is alot of value, and of course understanding how DI helps that is important. It’s value comes when you have code that is built with interfaces where you can use polymorphisms and interchange your components.

thanks again for the blog post.