+972 52-548-6969
Evaluating IoC containers
time to read 1 min | 162 words
Scott Hanselman is learning IoC, and he listed a lot of the IoC frameworks on the CLR. I was also pointed to this comparison IoC containers.
I don't like that comparison, and I am not sure that I can quite explain it. Most of the time, comparison of IoC container focus on simple dependency resolving scenarios and the related configuration.
From my point of view, it is like deciding to use C# or Java after reading a comparison of the syntax of an if statement.
Dependency resolution is the most basic feature that an IoC container can have.
Of the top of my head (and probably biased toward Windsor, since that is what I tend to use), I would say that you need to think about the following points, instead of focusing on the baseline scenario:
- Error handling
- Generic components
- Decorators
- Interception
- Configuration vs. Convention (in other words, how much smarts does the container have?)
- Extensibility scenarios
Comments
Going strictly off the dependency resolution features, one might be led to believe this was the grandaddy of all IoC containers:
set rs=Server.CreateObject("ADODB.recordset")
lol
LOL
You are right!
Hi Ayende,
Just a quick nitpick (or not, I could be wrong), but - are you now equating IoC with dynamic class loading? (yes, I saw the "LOL", but still...)
I personally don't understand why you seem to refer to Dependency Injection and Service Location as IoC all the time. To me IoC is about who controls the flow of the app...an obvious IoC example is a WinForms app where you no longer control the main loop - you just implement event handlers - in contrast to, say, a normal console app where you control the main loop yourself.
Dependency injection isn't inverting any control that I can see - you call a library (or have it called implicitly at startup) that will create some instances and configure them for you - what's inverted? Same with service locator - you call a service location lib, not much of the application flow becomes inverted as far as I can see?
But I know it is at least very common to refer to DI as IoC, even while I don't agree with/understand it....but to go so far as calling dynamic class loading IoC...isn't that trying to port the buzzword a bit far?
/Mats
No, IoC != Dynamic class loading.
An IoC container is a suitable place to handle dynamic class loading, but this is beside the point.
IoC is often used as a shortcut for IoC container.
In my case, it refers both to the usage of the container and to the actual inversion of control in the application. Most of my apps are composed of a core infrastructure and the app builds on top of that. That core infrastructure implements IoC for the rest of the app.
aahhh....OK I think I'm starting to see how you mean. Thanks for spelling it out, I've never really clearly understood how one arrives at using the term IoC like that and it seems people who do understand it (and do it) always think it so obvious they leave out half the steps when they try to explain to me! :-)
Big thanks, this usage of the term has actually been profoundly confusing to me for a long time now :-P
/Mats
Comment preview