differences between IoC containers

Question

I'm looking for some guidance about how to chose an IoC container for an ASP.NET MVC application.

What are the differences between (for example) StructureMap, Ninject, Castle Windsor, Unity, autofac and others? Can anyone give some hints or links to resource that might help chosing one library?

Update: there is one question (http://stackoverflow.com/questions/411660/enterprise-library-unity-vs-other-ioc-containers) which talks about the differences in the initialization of the IoC containers.

But are there any differences in functionality, which would make some IoC containers a better choice for an ASP.NET MVC application?

Answer 1

Hi Martin,

Here's a helpful blog post that compares features between the various IOC frameworks available in .Net, I don't know that there's anything about MVC that favors one container over another though.

Max

Answer 2

I've personally settled on Autofac. One thing that seems to be really nice is the deterministic disposal of resources.

That and it had ASP.Net integration with it as well when I checked it out. I should look at other frameworks some time but I haven't had issues with it. The error messages it gives you when there is an unresolvable component is really nice.

Your best bet is to try projects with each of them. I've become a real fan of doing the configurations in code (as much as possible) and using XML configurations as backup. So make your own priority list and try them out.

Answer 3

One thing which is different between the various IoC containers are the lifecycle or instantiation modes which are supported out of the box (when to create a new instance of the component):

• StructureMap
  • transient (called per-request), singleton, thread-local, per-HttpContext, per-HttpSession, Hybrid
• Ninject
  • transient, singleton, per-thread, per-HttpRequest
• Castle windsor
  • singleton, transient, per-thread, pooled
• autofac
  • transient (factory), singleton, per-HttpRequest
• Unity
  • transient, singleton, per-thread

Answer 4

Personally - this is where OOP stops being the right solution, because it doesn't handle IoC that well. Finding your own solution may be the better. Personally I roll my own with F# - as long as I can control both ends.

The new Rx may help some of these issues, but still it's just borrowing a bandaid from functional programming.

I guess we are stuck with objects as a basic model for some things for a while though - luckily in web services objects worked so badly that the standards have already moved away from them towards functional interfaces like SOAP.