.NET has a lot of IoC containers. This is undoubtedly a good thing: diversification is a sign of strength in the ecosystem. MEF is showing how specialization can be used to solve specific issues. I’m going to try to set out one vision of how IoC containers should evolve. This is not my opinion of how they all should evolve, it’s simply my vision of what I would like from one of the many containers.
I’ve argued for some time that containers are all about configuration. If you don’t believe that, then you should consider why Yadic isn’t your favourite container. I’ve also been agitating for some time to get environmental deltas included in Castle Windsor, but actually this doesn’t even go far enough. Let’s talk about what’s still wrong:
- There’s no standard way to specify external configuration. (i.e. you can’t separate configuration from wiring)
- There’s no standard way to examine the runtime configuration.
- There’s no standard way to report of the validity of the runtime configuration.
- There’s no standard way of having a centralised configuration source.
- There’s no sensible way of changing the configuration other than hacking files around.
- You can’t change the runtime configuration and have that reflected in the state of the container. Live.
Binsor achieves the first in a general way, but in a fashion that isn’t really acceptable. nServiceBus thinks this through a lot, but only solves it for the case of using nServiceBus. StructureMap provides the second at an API level, but not at an ops level.
Live Diagnostics
StructureMap has, at the time of writing, much better diagnostics than Castle Windsor, which still firmly believes in the “try activating the component and see if it throws an exception” model. However, why can’t we do the following?
- Ability to embed a web server in your application. Seriously, why do we keep writing remoting+winforms applications just to do simple diagnostics?
- Ability to see all of the live configuration options.
- The ability to modify the live configuration options.
- Ability to see which configuration settings have issues.
You might think I’m talking futurology here, but Sam Newman and his mates have already built it. (You should watch the entire talk.) There’s no reason that work can’t be generalised in an opinionated manner that requires developers to think about these issues up front.
A possible objection is that this functionality is pretty much orthogonal to what containers do right now. That’s correct to a certain extent, but it ignores a fundamental issue: every container I’ve used (let’s ignore MEF for now) works on the basis that, ultimately, the configuration for an application can be expressed as an XML file. This expresses itself in a number of ways:
- Things are strings that shouldn’t be.
- Configuration can’t change during the lifetime of the container.
- The container can’t recreate objects based on a change in configuration. There’s no model for even expressing how that lifecycle should work.
Viewed from a certain angle, IoC containers at the moment are basically better XML configuration files. There’s no reason they can’t be a better WMI.
Colour Coding 
Hi, I like the idea. It’s a definitely an improvement. There’s a couple of extra things I’d like to see:1) The status message hides the most important information: the cause. I understand that it’s useful to have the full stack trace there, but maybe a RootCauseComponent and a DependencyMissing property would work. So if the "fixHandler" component hadn’t got the "port" constructor parameter set, you’d see "fixHandler" and "port" respectively. (You can have multiple problems, but I’m trying to think of ways to get the information to developers as fast as possible.2) I’d like to be able to say "if I provide these parameters, will X resolve?". This is particularly important when you resolve objects using user inputs or command line parameters.I’ve actually started work on the web server bit. I’ll talk about that more when it’s looking even half usable.
LikeLike