There are a number of reasons why Dependency Injection is a good thing, and many people of high esteem have written about it. Hopefully only those developers completely cut off from modern-day communications are left with a good excuse not to know about this subject.

Do I sound too dogmatic? Well, to be honest, if you are undertaking a project of a certain degree of complexity that is meant to be maintainable I find the use of a DI framework easier to justify than not using it. It really helps to get to grips with a clean OO-approach. It helps your code to stay SOLID.

As a .NET developer you are indeed spoiled with choice - it’s almost like back in Java, if you know what I mean. Which DI Container should you take?

This post could be interpreted as a starting point to get links and a few warm words to the choice available. Without further ado, let’s get going…

Castle Windsor

Castle Windsor is the first DI container I have used in .NET. It is quite present in the community since it has links to some other very popular frameworks, ActiveRecord (a design pattern in itself which you will have to consciously choose but which will make your life with NHibernate a lot easier once you do) and MonoRail, which was giving you rails long before Microsoft figured out what MVC could mean for the web generation.

Castle Windsor’s official download is of a “Version 1 Release Candidate 3”. This does not tell much of the quality, because the features you get are well tested and can be used without problems in a production environment. I have once made a comparison performance wise of Spring.NET and Castle Windsor here, which will show you a basic configuration scenario.

We used said version and the best way to configure it was via (an) XML file(s). All major concerns you expect to be solved by DI are solved, however the configuration via XML can get nasty, especially when you use generic classes and interfaces (IDictionary`2[[System.String, mscorlib],[System.String, mscorlib]] anyone?).

Castle Windsor is probably the largest of all DI containers I know as it has legions of additional functionality. The only sensible way to get to them is to pull down their current trunk. In my opinion it makes the project less accessible than others. Either way, if you want your container to also handle e.g. WCF integration and also get your hands on a fluent interface to handle the configuration side of things, it is worth having a look into this project (Also see why I couldn’t get my INotifyPropertyChanged proxy to work with the 1.0RC3 version of DynamicProxy2). One of the system’s selling point is also the possibility to change the configuration during system runtime, something not allowed by every DI container.

Lastly, one of the contributors, Hamilton Verissimo, aka hammett, will be joining Microsoft. Although he states that nothing changes for Castle, I am wondering whether his efforts won’t be needed to give Unity a stronger voice in the community.

Spring.NET

There is not much I can tell about this one, apart from the fact that I know the name from old Java times and that it looks like Java devs would probably go for Spring.NET since they would feel right at home. It was presented at our company and from what I can see it should provide you with typical DI functionality, but I commonly hear that the configuration side of things is rather heavy (where’s my “say NO to XML” shirt?).

Ninject

This is a recent addition to the landscape, a system developed by Nate Kohari. This is one container that leaves behind XML files for a fluent API to be talked to with your MSIL beautifier of choice. Additionally, the introduction of something Nate calls contextual binding makes for some interesting functionality:

// Adding some spice to the "Bind" call Ninject provides in its "Modules"
protected ViewModelSetup<M> RegisterModel<M>(string modelID) where M : IViewModel
{
  Bind<IViewModel>().To<M>().Only(When.Context.Variable(BaseWindow.ModelID).EqualTo(modelID));
  return new ViewModelSetup<M>(this, modelID);
}
// ...somewhere else...
public ViewModelSetup<M> WithControls(ControlMap controlMap)
{
  module.Bind<ControlMap>().ToConstant(controlMap).ForMembersOf<M>();
  return this;
}

This is just one example of a number of possibilities. The idea is to provide dependencies based on the context of your request, be it that you add your own stuff to a present context object or that it allows you to state things like “Dependency d should be satisfied with object x provided that the target parameter y is decorated with attribute A.”.

The configuration interface is lovely, you probably won’t miss the fact that there is no XML configuration available. The framework is quite usable and has a good performance for what it does (but also not orders of magnitude away from other DI servicing candidates).

For me the most problematic current omission (Ninject is in Version 1) is that I cannot define n classes all satisfying service s and get all those dependencies at once e.g. in the form of an array like s[].

Documentation is there for the most basic scenarios but if you get stuck it’s best to post something on Ninject’s usergroup.

StructureMap

This container seems to have been around for quite some time, and there are a number of mainainers, most notably the creator Jeremy Miller, and just mentioning Chad Myers, since he has been helping out with some nice explanatory blog posts on Structuremap (code here).

During the past half a year I tried once or twice to break into its mindset. The third time round just a few days ago I finally made some progress into it, so far that it feels like it could be the right choice for one of my upcoming projects. Let me try and explain why.

• While this thing does have some XML config layer, much effort is going into a fluent interface for configuration.* Support of arrays of stuff is strong (pipelines are not only a Russian thing).
• Attributes PluginFamily and Plugin allow for easy implementations of …plugins (doh!).
• Defining autowiring capabilities based on your own implementation of a TypeScanner, thereby allowing you to state conventions on how to bind together stuff, is just plain neat. Why shouldn’t a FunkDataSet be automatically bound to a FunkModel, if it is depending on one? (Yeah, go flak me for using the D-word!)
• Jeremy and colleagues seem to be working away towards version 2.5 of StructureMap which seems to fully embrace 3.5 framework capabilities. I haven’t looked much at the code yet, but some parts make heavy use of Expressions which should allow you to write some really expressive ;) code.

StructureMap also has a user group over here.

AutoFac

This is really just a pointer. I can’t say anything about it since I haven’t tried it yet. If anything changes about that I will gladly post here.

Unity

Same goes to Unity. No hands-on experience yet. I should certainly note that this is Microsoft’s offering in this matter, with Unity being part of the grand scheme of Enterprise Application blocks.

I hope you enjoyed this post and feel free to comment about your own experiences with any of the listed frameworks or if I did completely miss some offering.