DI, IoC => windsor Wins

After a long time a chance came around to use Windsor in one of the projects. While refactoring the code I realized we had coupled few components way too tightly. Thus their upgrade, pluggability were getting hindered. At that time we had very less time and no luxury of evaluating the frameworks.  Now in some down time, I realized Windsor  is a perfect lazy programmer’s helper. Do minmum independent work in one class and keep the dependency in form of behavior (interfaces).  Keep the implementation of interface at a distance and use a framework to resolve the relationship.

No I am not using it becuase it makes the testing easy. I have the pluggability as main concern. Use of factory/service locator etc was not going to give this kind of ease.  One of the days when I have time, I will trim the code and dump it here for before and after image.

A day of work with windsor convinced me about its elegant design and use. It is pretty powerful in its services/Dependency Solver/Facilities and related extensibility model.

Related important documentation – configuration (.chm file is not so good for explaining the items), it gets complex at times if you have lot of items you want to decouple. It would be wiser to use include files or Boo-DSL-Binsor.  That is the only downside of the these frameworks (spring.Net) as they make debuggability – hard. One needs to look at 2 different places for the information. 

Tip – type is fully qualified type information. When directly using kernel you may not encounter any errors as was in my case but one would be insulted when using the configuration method. So always remember this when providing information, (same applies to service information)


Good tutorial – BitterCode.

Download location – Castle.  They also have the MonoRail which started the push for asp.net mvc framework in many ways.

Alternatives are ninject, spring.net, pico/nano. On java side the one which is more exciting is guice. The video of guice is little better intro compared to msdn articles. But don’t worry it is just factory pattern/strategey.

Common things

– injection of constructor, setter etc, interceptors (method )

– lifetime, security + AOP concerns

– use of config files(ninject has different attribute based approach) to provide default information to decouple.

Nothing new for folks who have seen the early remoting days and evolution of wcf in its container avatarand folks who use the terms like strategey/factory pattern. Just a big time saver. It should be used carefully depending on how much time you want other people to learn a framework vs your container approach.

I wished CLR team extended the Binderand friends in elegant way for general usage, Objectbuilder(/Unity) does not inspire confidence. 

Activator.Createinstance !

Anyway – another good thing for last 2 weeks was xunit. So xunit+waitn should cover most of the scenarios for us. Compared to nUnit/MBUnit – it was dead easy( I am hoping I am not betting on always in beta work though). Battle is still on between Moq and RhinoMocks. I am still refactoring like crazy to enable most of the essential control.  Waiting for spec# to have some official lifeline.

DI, IoC => windsor Wins

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s