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

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.