IoC and The Sweet Sweet Taste of Humble Pie

After criticizing Castle’s MicroKernel and Windsor last night for not clearly differentiating themselves from the built-in IoC container in .NET (IContainer) I awoke to a fairly polite smackdown from hammett (now subscribed) of the castle project. Today after reading some new material on IoC, Spring and Castle (and re-reading the stuff I’d read on IoC some time ago) I can see why it probably didn’t occur to the Castle folks to “compare and constrast” with System.ComponentModel. IoC (inversion of control) containers come (for the most part) in two great flavors - dependency injection and service locators. Castle’s MicroKernel and Windsor are (seem to be) the former type - they can inject dependencies into things for you either via the constructor (called constructor injection) or via setter properties (setter injection) which sounds quite useful, and seems to be referred to as “auto-wireup“. System.ComponentModel is more of the second type of IoC container - a dynamic service locator [1]. You can ask for a service of a particular type and the container will provide a service of that type to you if one has been registered. Service locators are very explicit - it is entirely apparent that you’re using this pattern and that services are coming form “somewhere else”. With the former kind the “client“ object is not aware that these dependencies are being injected from a container, they just look like plain ‘ole objects that could have been new()ed up explicitly by a caller and passed in. Because of these fairly fundamental differences it probably didn’t occur to them to compare themselves to the classes in System.ComponentModel.

Picking fights with people smarter than you is great - you always end up learning something

This re-visiting of IoC has been quite interesting. For one I quite like the idea of the different component “lifestyles“ that Windsor provides - Singleton, Transient, Per-Thread and Pooled. To have that kind of “infrastructure“ code factored out of your domain objects sounds extremely useful. Also its bought some clarity regarding the VS object model, another very obvious use of the dynamic service locator pattern. I think I’d like to give Windsor or Spring.NET a try.

[1] - although (just to confuse things) IContainer does inject one thing into IComponets that are added to it - the dynamic service locator ISite. I’ve heard this referred to as “service injection”.

Comments

hammett
You got it. Btw we support the ComponentModel interface as a mean to hide the container implementation from your application - so you can switch off castle in favor of well, something else.

http://svn.castleproject.org/svn/castle/trunk/InversionOfControl/Castle.Windsor/Adapters/ComponentModel/

There is some discussion about that here:
http://forum.castleproject.org/posts/list/14.page

Cheers!
22/08/2005 7:01:00 AM
Mitch Denny
You would think with all controls in a Windows application ultimately implementing IComponent that you could use the service locator pattern to build a quite well integrated application.

But no! When controls are added to the controls collection they don’t get sited correctly. System.ComponentModel is actually broken in so many ways.
22/08/2005 2:13:00 PM