The Real Reason to Use IoC/DI (Inversion of Control/Dependency Injection) and a Container Like Windsor

Can you imagine maintenance where you would only have to change a configuration? How about not having to touch existing production code but be able to completely change the behavior of an existing application?!

The real reason to use a dependency injection container is Maintenance. When considering that after you write your first line of code, everything from that point on is maintenance, maintenance is a pretty big deal.  Containers make changes seamless. Actually, interface-based development makes changes easier. Being able to push an implementation of that interface into the dependent objects when constructing them (dependency injection) makes changes seamless. And being able to push that all to the container configuration: awesome!

Case in point, yesterday I was asked to look into changing a notification system.  I added a new implementation of the interface the application was using, changed the configuration, and I was done. I didn't have to go into the application's code and make any changes at all! That is powerful. I changed the behavior of the application without touching a line of existing code!!!

Another way to do it? In my recent presentation at KC Day of Dot Net, a question came up about using Windsor to make changes to existing code in production without actually changing any code or redeploying existing DLLs. The question was "Can you have Windsor use an assembly the application doesn't have a reference to?" The idea is that you need to change functionality of a certain piece of the application, but you can't change the existing code at all.  This means you cannot add any references to new code or put new code into the existing program.  How would you do this?

Implementing new Behaviors Without Changing a Line of Existing Code

It's actually very simple when you are using inversion of control containers.  Basically you could use Windsor and a new DLL that implements new behaviors on existing interfaces that the application uses.  Then you would put that new DLL next to the rest of the application code and change the information in the container configuration to point to the new code.

1. So we have our employee.system implementation of a simple HR system.  Now we create a project call employee.system.additional and reference the code that has the interface we need to implement.

image

2. Then we create our implementation of the interface. This is a new implementation of ICommand.  It's very simple, it just logs a message.

image

3. After we are done, we build the new assembly and take that that DLL and place it in the same folder as the existing code.

image

4. Then we crack open the Configuration file and make some changes to allow us to use the new DLL's code (the existing code doesn't even know of this new assembly).

image

5. Then we just run the application. We just completely changed the behavior of the application and changed ZERO lines of code in the existing app!!!!

image

Could you imagine maintenance where you would only have to change a configuration?  And not having to touch production code but be able to influence change!

Download the sample here using SVN: https://robz.homedns.org/svn/Presentations/trunk/IoCPresentation/

Print | posted @ Sunday, December 14, 2008 1:11 AM

Comments on this entry:

Gravatar # re: The Real Reason to Use a Dependency Injection Container Like Windsor
by John Miller at 12/14/2008 7:47 AM

You mean IoC has purposes outside of unit testing? :)

Another great write-up, Rob!
Gravatar # re: The Real Reason to Use IoC/DI (Inversion of Control/Dependency Injection) and a Container Like Windsor
by Robz at 12/15/2008 10:17 AM

@John: Thanks man!
Comments have been closed on this topic.