Comparing Castle Windsor, Unity and StructureMap

Question

In a follow up to Krzysztof’s statement that Windsor does a lot more than other IoC’s, I wanted to understand how these IoC’s stack up against each other and the benefits/ad

Answer 1

See here and here for a pretty thorough technical comparison of several IoC containers, although somewhat outdated by now (they're from before Windsor 2.0)

However, I don't think there are really any vital features that Windsor offers and other containers don't. Windsor, StructureMap, Spring.NET have all been around for several years and have been used in lots of projects over these years so they're very mature now. Newer containers, like Autofac, Unity, Ninject and SimpleInjector build on that previous experience so they won't lack those vital features either.

Now the more subjective part of the answer: I like to think that Windsor has a nice mix of usability, extensibility and integration modules.

Usability: for example, you can use XML and/or code registration (it also has a fluent API like most containers nowadays).

Extensibility: Lots of extension points that you can use to customize or override pretty much any default behavior.

Integration: Windsor has lots of facilities (modules) that allow for easy integration with other frameworks/libraries. Other integrations include ASP.NET MVC, MonoRail, Workflow Foundation, NServiceBus, MassTransit, Rhino Service Bus, Quartz.Net, SolrNet, SolrSharp, Windows Fax Services.

This series of articles covers many niceties and extension points of Windsor.

Note that I'm not saying that other containers don't offer similar things! Even if you picked one of them and later you found out it's lacking some integration, it's usually not hard to code it yourself.

Bottom line: I don't think you can go wrong with any of the main IoC containers, as long as you structure your code properly (e.g. avoid the service locator anti-pattern).

Answer 2

For me there are two killer features of Windsor that I don't believe most other containers provide.

• Ability to work in a container agnostic way - this means your container can bootstrap all the code for you and you can take full advantage of its rich capabilities without ever referencing any of Castle.*.dll assemblies in your non-infrastructure assemblies. This is thanks to features such as Lazy Component Loaders, DynamicParameters and Typed Factory Facility, which do not constraint you from taking advantage of advanced capabilities of the container, while avoiding manually coding integration layer, or using Service Locator, which as @ploeh wrote is an anti pattern.

• very rich extensibility/extensions ecosystem which can give you really powerful capabilities and greatly reduce amount of plumbing code you have to write. This may not sound powerful, but you will appreciate it once you take advantage of things like WCF Facility in one project, and then in another you won't be able to use it. The extensibility part means that while Windsor does not try (this is its design goal) to solve every issue you may have out of the box, it is very extensible, which means you can tweak and twist it to do almost anything you may need.

Other than that I just happen to like the way Windsor works pretty much as expected (contrary to some other containers) and how it solves the little things. For example creating decorated services is very simple. I also like it's fluent registration API very much, which works very well for both simple scenarios, and does not get too twisted and complicated when you want to do something advanced. Plus a lot of other small things although here things can be pretty subjective.