I’ve been using Castle Windsor for some time now. The way I use it is probably non-standard and that’s why its proving quite hard to find an alternative for it. So I decided to download a a nice selection from Scott Hanselmans listof IoC containers and give them a go.

First let me explain why I’m looking for an alternative when Castle Windsor is clearly one of the most used and most capable IoC containers out there. Its actually quite simple. The last official Castle release was in 2007 and that was only a release candidate for version 1.0. An official version 1 has never been released. For me personally that’s no problem. The project is still being worked on, new features are being added and its easy to pick up the latest version from the SVN trunk, build it and use it. There are even new releases planned. But its a hard sell to use it in commercial projects. I need something that’s mature and visibly supported. Shouldn’t be too hard right?

There is one feature I would like to have in my new IoC container and that’s the IInitializable or something that can take it’s place. Let me explain.

Most getting-started guides on dependency injection and IoC the first thing they show you is how to do constructor injection. Constructor injection is very powerful because your component is never half-initialized. It always has all its dependencies set. But I like property injection better, for the simple reason that property injection gives me more flexible code. Changing around dependencies is easier because I don’t have to rewrite all the tests where I still call constructors explicitly. In order to still be able to do some initialization after all dependencies are set in my component I made extensive use of Castle’s IInitializable. This is an interface that specifies one method: Initialize() and Castle guaranteed it to be called after the components dependencies were set.

So the search begins:

But first a disclaimer. I’m not claiming one IoC container is better than another, I’m just looking for an IoC container to support one non-standard usage scenario.

Unity

This is where I started looking. Unity is a Microsoft product. Its supported by the Patterns and Practices team so support is more or less guaranteed (unless they pull a “Linq to SQL” and drop it in favor of its bigger brother, MEF) It should be an easy sell. Unfortunately its not really mature yet and for instance doesn’t support my initialization scenario.

Spring.Net

Spring.Net actually gave me the biggest surprise. It works quite differently from what I’ve come to expect of IoC containers. Instead of mapping Interface-types to classes it maps string-keys to classes. Auto-wiring is harder this way. In most cases you have to explicitly specify dependencies between components. No go there. And that’s unfortunate because it seems Spring.Net has the best support for my initialization scenario I’ve seen yet. No need for interfaces. Spring.Net just calls Start() on any component that has that method. This is a nice example of convention over configuration.

Autofac

Ah, thats more like it. Autofac supports my initialization scenario. Not in one but in two ways. You can specify an OnActivating eventhandler when registering a component or you can use the Autofac.Contrib.Startable module. Neither way is as clean as Spring.Net’s Start() method or even Castle’s IInitializable. But they will do. Autofac.Contrib.Startable is not ideal because it forces you to start all components at registration time, normally components are initialized lazilly when they are needed. The eventhandler scenario forces you to write eventhandlers to call the startup-routines.

Other than that Autofac seems to be just what I need. It has a nice and simple ‘DSL’ for configuring the contianer. It doesn’t have all the bells and whistles Castle has but it has bells and whistles I might actually use like ASP.Net MVC integration.

Structuremap

Last but not least is StructureMap. StructureMap and Autofac are on par when it comes to features. StructureMaps DSL for configuring the container is a bit more extensive. For me this is a good thing. Configuring setup of components can be done with a lambda expression, this is a bit easier than the event-handlers used with Autofac. But other than that the DSL seems a bit contrived in places.

I’ll probably try both Structuremap and Autofac for a while. All IoC containers have similar features and differences are quite subtle. Right now I lean towards Autofac for it’s simpler configuration although Structuremap seems to support the one usage-scenario I thought up a bit better.