Castle Windsor is an inversion of control tool. There are others like it.
It can give you objects with pre-built and pre-wired dependencies right in there. An entire object graph created via reflection and configuration rather than the "new" operator.
Start here: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Imagine you have an email sending class. EmailSender. Imagine you have another class WorkflowStepper. Inside WorkflowStepper you need to use EmailSender.
You could always say new EmailSender().Send(emailMessage);
but that - the use of new
- creates a TIGHT COUPLING that is hard to change. (this is a tiny contrived example after all)
So what if, instead of newing this bad boy up inside WorkflowStepper, you just passed it into the constructor?
So then whoever called it had to new up the EmailSender.
new WorkflowStepper(emailSender).Step()
Imagine you have hundreds of these little classes that only have one responsibility (google SRP).. and you use a few of them in WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Imagine not worrying about the details of EmailSender
when you are writing WorkflowStepper
or AlertRegistry
You just worry about the concern you are working with.
Imagine this whole graph (tree) of objects and dependencies gets wired up at RUN TIME, so that when you do this:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
you get a real deal WorkflowStepper
with all the dependencies automatically filled in where you need them.
There is no new
It just happens - because it knows what needs what.
And you can write fewer defects with better designed, DRY code in a testable and repeatable way.
You should check out S#arp Architecture. Comes with a VS project template, has all the binaries you will need to get up and running very quickly. Uses ASP.NET MVC 1.0, NHibernate 2.0.1 (but 2.1 has been documented and will work), Castle, etc.
It's a great framework. Awesome documentation and a very helpful user community.
Best Answer
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).