What should I consider when choosing a dependency injection framework for .NET

Question

see also Which C#/.NET Dependency Injection frameworks are worth looking into?

There are now many dependency injection frameworks to choose from. You used to often be forced to use a given dependency injection framework due to a library you were using. However the Common Service Locator library has enabled library code to be independent of injection frameworks.

The time it takes to learn all of them well enough to decide which to use is unreasonable. I don’t believe that we have yet reached a stage that we can talk about the best dependency injection framework. So what questions should I be asking about the project and myself to help decide on the best dependency injection framework to use in a given case?

It would also be useful to know why you choose the dependency injection framework you are currently using and if you are still happy with that choose.

Is there yet a useful vocabulary to use when comparing the styles of dependency injection frameworks?

Does the Service Locator library work in real life, or are you skill forced to use lots of different dependency injection frameworks in the same project?

How easy is to refractor you code with each Dependency Injection Framework, e.g do tools like ReSharper work well with a given framework?

Answer 1

FYI, just this morning I came across an interesting comparison between all the .NET IoC containers here:

http://elegantcode.com/2009/01/07/ioc-libraries-compared/

A handful of questions:

1. How much mainstream support do you need? Spring is probably the biggest one out there. Everyone has used it or has heard of it by now, so lots of info. It also probably has the largest number of features, but that means there's just more to learn. A smaller container like Autofac might be nice, but you might come across an issue you won't find help on.
2. Are you handy w/ Xml configuration? Every IoC container relies on configuration and setup of some sort. Spring and Unity are Xml heavy.
3. Is this a permanent choice? If you are at one of those places where you only get one shot at a choice, it won't matter. But, if you ever want to choose another solution down the road, you probably don't want an IoC that requires you to attribute your classes (sorta the inverse of the above question) because you'll hate yourself when you have to rip all that stuff out. In comparison, wwapping out some xml config might not be as painful.
4. What's your shop like? I had trouble pitching a couple open source options just because of the "gasp! it's not Microsoft!" reactions. If you're a straight MS shop, using Unity will be a much easier cultural win.

On a personal note:

I've used StructureMap for the same reasons mentioned in the blog I linked. I think Xml config is a giant pain to maintain and, especially, debug (see WCF). I haven't tried Ninject yet, but based on their marketing, it must be super rad!

Answer 2

I think the choice comes down to finding a framework that meets your requirements and then personal preference.

Does your project already use a library such as rhino-tools that already integrates with a DI framework? If it does, that might be a good starting point if you want to avoid using "lots of different dependency injection frameworks".

Check out these two posts:

• SO: Enterprise Library Unity vs Other IoC Containers
• SO: Which .NET dependency injection framework do you use?

Answer 3

Spring and Unity are Xml heavy.

I would disagree with that statement for Unity; you can write

container.RegisterType<IRobot, MrRoboto>();

and do your setup in code using a fluent-style interface. Personally I like Unity.

Answer 4

It's hard to answer which framework is 'best', but I can tell you which framework is the simplest: The Simple Service Locator.

"The Simple Service Locator is an easy-to-use Dependency Injection library that is a complete implementation of the Common Service Locator interface. It solely supports code-based configuration and is an ideal starting point for developers unfamiliar with larger DI libraries."

http://simpleservicelocator.codeplex.com/