Geek Answers Handbook

Differences between IoC containers

I am looking for some recommendations on how to choose an IoC container for an ASP.NET MVC application.

What is the difference between (e.g.) StructureMap, Ninject, Castle Windsor, Unity, autofac and others? Can someone give tips or links to resources that can help in choosing one library?

Update : There is one question ( Enterprise Library Unity vs Other IoC Containers ) that talks about the differences in initializing IoC containers.

But are there any differences in functionality that will make some IoC containers the best choice for an ASP.NET MVC application?

+4
source share
4 answers

Here's a useful blog post that compares functions between the various IOC structures available on .Net, I don't know something about MVC that supports one container over another, though.

Max

+5
source

One of the differences between the various IoC containers is the lifecycle or instantiation modes that are supported out of the box (when you need 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
  • Windsor castle
    • singleton, transient, for streaming, combined, for-HttpRequest (optional accessible via objects)
  • autofac
    • transient (factory), singleton, per-HttpRequest
  • Unity
    • transitional, singleton, per-thread
+6
source

I personally settled on Autofac. One thing that seems really enjoyable is the deterministic disposition of resources.

This and I had ASP.Net integration with her when I tested it. I should take a look at other frameworks for a while, but I had no problems with this. The error messages it gives you when there is an unsolvable component are really nice.

It is best to try projects with each of them. I became a true fan of creating code configurations (as much as possible) and using XML configurations as a backup. So make your own priority list and try them.

+1
source

Personally, this is where OOP ceases to be the right solution because it does not handle IoC very well. Finding your own solution might be better. Personally, I roll back with F # - while I can control both ends.

The new Rx may help some of these problems, but still it just borrows a gang from functional programming.

I think that for some time we linger on objects as the basic model for some things - fortunately, objects worked so poorly in web services that standards already moved away from them to functional interfaces such as SOAP.

-one
source

More articles:


All Articles