views:

2423

answers:

10

I am thinking about using Microsoft Unity for my Dependency Injection tool in our User Interface.

Our Middle Tier already uses Castle Windsor, but I am thinking I should stick with Microsoft.

Does anyone have any thoughts about what the best Dependency Injection tool is?

  • Autofac
  • Castle MicroKernel/Windsor
  • ObjectBuilder
  • PicoContainer.NET
  • Puzzle.NFactory
  • Spring.NET
  • StructureMap
  • Ninject
  • Unity
  • NauckIT.MicroKernel
  • WINTER4NET
+1  A: 

Ninject is a masterpiece. No need for XML configuration and fast as a whip.

Spring.NET would be my second choice given the amount of existing documentation, user group activity, etc. related to the original Java version.

I am always weary of using Microsoft versions of open source tools. It is not their core competency.

Ben Hoffstein
Ninject looked really good, although I found that you can not link several containers together.. which I think is a bit of a failing. Something to consider
Xian
+3  A: 

I'm an Autofac fan, but both Windsor and Unity will do a good job (though Windsor is more capable than unity and doesn't require attributing your code). There's plenty of good non technical reasons for sticking to a single container in a system though.

What makes you say (implied) that Unity requires you to attribute your code? I'm using it and don't have to attribute my code at all.
Anthony
+1  A: 

http://stackoverflow.com/questions/71041/which-single-iocdi-container-would-you-recommend-using-and-why

Vinko Vrsalovic
Yup, bonafide dupe.
Ben Hoffstein
His question has more data than the original, so I recommend against closing.
Portman
+1  A: 

Use what works. Most have features that are unique to them, and almost all are more feature-rich than Unity. If unity is all that you need, you can certainly use it.

Using Microsoft's unity just because it's from Microsoft is a poor way to make a decision. Think about what you need and why, and choose the one that fits your needs.

However, I second the notion of sticking to a single container if possible.

Philip Rieck
+7  A: 

Sticking to one container is not really important, if your system has been designed with the IoC/DI in mind. With the proper approach you can easily change the IoC library down the road.

And, of course, the container has to provide enough flexibility to support common widely used scenarios (lifecycle management, proper container nesting, XML and code configuration, interception, fast resolution).

I'd recommend to pick between Castle (widely used and have a lot of integration libraries) and Autofac (lightweight, fast and has proper container nesting, but is not that widely used)

There is a comprehensive list of IoC containers by Hanselman

PS: You do not want to use Unity

Rinat Abdullin
Can you please elaborate on the Unity remark? Why is it a bad choice?
vitule
Agreed about Unity.
Krzysztof Koźmic
after using ent lib before windsor - i have a very negative and allergic reaction to any attempt by MS to create any thing like a "policy injector"!!asp.net mvc aside :)
cvista
+9  A: 

Here is a good article which compares .NET IoC containers. http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/

aogan
Wow, that article has an amazing amount of detail. Totally worth the read. It also has a part 2: http://blog.ashmind.com/index.php/2008/09/08/comparing-net-di-ioc-frameworks-part-2/
Joe White
A: 

Unless you already have experience and a personal preferance for a particular sub-technology utilized by one of the possible IoC container solutions, they all function well and I don't see any one in particular with a "killer function" that makes it stand out from the others. Unity is probably the best fit for solutions already utilizing the P&P Enterprise Library 4.x...

Scott Wade
+44  A: 

Having recently spiked the use of 6 of these (Windsor, Unity, Spring.Net, Autofac, Ninject, StructureMap) I can offer a quick summary of each, our selection criteria and our final choice.

Note: we did not look at PicoContainer.Net as one of our team considered the .Net port to be quite poor from the Java version. We also did not look at ObjectBuilder, as Unity is built on top of ObjectBuilder2 and was considered to be a superior choice by default.

Firstly, I can say that more or less all of them are all pretty similar and it really comes down to what really works best for you, and your specific requirements. Our requirements included;

Requirements

  • Constructor based injection (we intend not to use property, field or method injection)
  • Programmable configuration (not XML)
  • container hierarchies (one per application, per request and per session to more implicitly bind component lifetimes scope to container)
  • component lifetime management (for more granular scoping eg transient / singleton)
  • injection from interface to type or concrete instance (eg ILogger -> typeof(FileLogger) or ILogger -> new FileLogger() )
  • advanced component creation / "creaton event mechanism" for pre/post initialisation
  • correct disposal of IDisposable components on container tear down
  • well documented and/or online information readily available

    Note: whilst performance was a requirement it was not factored in the selection as it seemed that all containers reviewed were similar according to this benchmark

Test

Each container was used in a typical Asp.Net webforms project (as this was our target application type). We used a single simple page with with a single simple user control, each inheriting from a base page / base control respectively. We used 1 container on the BasePage for a "per request" scope container and 1 on the global.asax for an "application" scope and attempted to chain them together so dependencies could be resolved from both containers.

Each web application shared a contrived set of domain objects simulating multi-levels of dependency, scope type (singleton/transient) and also of managed and unmanaged classes (IDisposable required). The "top level" dependency components were manually injected from the methods on the basepage.

Results

Windsor - Satisfied all the criteria and has a good case history, blogger community and online documentation. Easy to use and probably the defacto choice. Advanced component creation through Factory facility. Also allowed chaining of individually created containers.

Spring.Net - Verbose and unhelpful documentation and no-obvious / easy for programmable configuration. Did not support generics. Not chosen

Ninject - Easy to use with good clear documentation. Powerful feature set fulfulling all our requirements except container hierarchies so unfortunately was not chosen.

StructureMap - Poorly documented, although had quite an advanced feature set that met all of our requirements, however there was no built-in mechanism for container hierarchies although could be hacked togther using for loops see here The lamda expression fluent interface did seem a little over complicated at first, although could be encapsulated away.

Unity - Well documented, easy to use and met all our selection criteria and has an easy extension mechanism to add the pre/post creation eventing mechanism we required. Child containers had to be created from a parent container.

Autofac - Well documented and relatively easy to use, although lambda expression configuration does seem a little over complicated however, again, can be easily encapsulated away. Component scoping is achieved through a "tagging" mechanism and all components are configured up front using a builder which was a little inconvenient. Child containers were created from a parent and assigned components from a "tag". Allowed generic injection.

Conclusion

Our final choice was between Windsor and Unity, and this time around we chose Unity due to its ease of use, documentation, extension system and with it being in "production" status.

Xian
Nice and intelligent reasoning.
Sandor Davidhazi
Interesting to see the accepted answer says to stay away from Unity while the most voted answer chooses Unity!
Abdu
Yes, I thought that was interesting too. We gave equal measure to all containers and ignored anti-MS bias. Every situation is different however and one should chose the solution that is right for them at that time. As it happens we ended re-inventing the wheel and wrote our own we are going to open source soon
Xian
_blatent_ plug, but off the back off my research I have created a lightweight container for .Net. I believe it is currently the fastest in the industry and encapsulates what I was looking for most in a IoC. Caveat emptor: Work in progress http://code.google.com/p/yadic/
Xian
What happened with this answer? The last part of it seems to be missing...
M4N
edited the question, so that it is displayed completely.(was because of this bug: http://meta.stackoverflow.com/questions/14097/answer-to-question-cut-in-the-middle-in-question-view-in-full-in-edit-view-clos)
M4N
+2  A: 

I started using Autofac a year ago and haven't looked back since..

Carl Hörberg
+1  A: 

I've been using the Managed Extensibility Framework and found it quite easy to work with. It's been integrated into .NET 4.

280Z28
MEF is not a IoC container: http://stackoverflow.com/questions/42251/whither-managed-extensibility-framework-for-net/98848#98848
Mauricio Scheffer
@Mauricio Scheffer: MEF uses a dependency injection pattern in solving many architectural problems people are facing when they start to consider bringing an IOC/DI framework into the project. The OP does not provide any indication that his needs stray outside the bounds of what MEF excels at, in which case it could be an easy, viable, and extremely lightweight option.
280Z28