As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which C#/.NET Dependency Injection frameworks are worth looking into?
And what can you say about their complexity and speed.
edit (not by the author): There is a comprehensive list of IoC frameworks available at https://github.com/quozd/awesome-dotnet/blob/master/README.md#ioc:
Castle Windsor - Castle Windsor is best of breed, mature Inversion of Control container available for .NET and Silverlight
Unity - Lightweight extensible dependency injection container with support for constructor, property, and method call injection
Autofac - An addictive .NET IoC container
DryIoc - Simple, fast all fully featured IoC container.
Ninject - The ninja of .NET dependency injectors
Spring.Net - Spring.NET is an open source application framework that makes building enterprise .NET applications easier
Lamar - A fast IoC container heavily optimized for usage within ASP.NET Core and other .NET server side applications.
LightInject - A ultra lightweight IoC container
Simple Injector - Simple Injector is an easy-to-use Dependency Injection (DI) library for .NET 4+ that supports Silverlight 4+, Windows Phone 8, Windows 8 including Universal apps and Mono.
Microsoft.Extensions.DependencyInjection - The default IoC container for ASP.NET Core applications.
Scrutor - Assembly scanning extensions for Microsoft.Extensions.DependencyInjection.
VS MEF - Managed Extensibility Framework (MEF) implementation used by Visual Studio.
TinyIoC - An easy to use, hassle free, Inversion of Control Container for small projects, libraries and beginners alike.
Stashbox - A lightweight, fast and portable dependency injection framework for .NET based solutions.
Original answer follows.
I suppose I might be being a bit picky here but it's important to note that DI (Dependency Injection) is a programming pattern and is facilitated by, but does not require, an IoC (Inversion of Control) framework. IoC frameworks just make DI much easier and they provide a host of other benefits over and above DI.
That being said, I'm sure that's what you were asking. About IoC Frameworks; I used to use Spring.Net and CastleWindsor a lot, but the real pain in the behind was all that pesky XML config you had to write! They're pretty much all moving this way now, so I have been using StructureMap for the last year or so, and since it has moved to a fluent config using strongly typed generics and a registry, my pain barrier in using IoC has dropped to below zero! I get an absolute kick out of knowing now that my IoC config is checked at compile-time (for the most part) and I have had nothing but joy with StructureMap and its speed. I won't say that the others were slow at runtime, but they were more difficult for me to setup and frustration often won the day.
Update
I've been using Ninject on my latest project and it has been an absolute pleasure to use. Words fail me a bit here, but (as we say in the UK) this framework is 'the Dogs'. I would highly recommend it for any green fields projects where you want to be up and running quickly. I got all I needed from a fantastic set of Ninject screencasts by Justin Etheredge. I can't see that retro-fitting Ninject into existing code being a problem at all, but then the same could be said of StructureMap in my experience. It'll be a tough choice going forward between those two, but I'd rather have competition than stagnation and there's a decent amount of healthy competition out there.
Other IoC screencasts can also be found here on Dimecasts.
It depends on what you are looking for, as they each have their pros and cons.
Spring.NET is the most mature as it comes out of Spring from the Java world. Spring has a very rich set of framework libraries that extend it to support Web, Windows, etc.
Castle Windsor is one of the most widely used in the .NET platform and has the largest ecosystem, is highly configurable / extensible, has custom lifetime management, AOP support, has inherent NHibernate support and is an all around awesome container. Windsor is part of an entire stack which includes Monorail, Active Record, etc. NHibernate itself builds on top of Windsor.
Structure Map has very rich and fine grained configuration through an internal DSL.
Autofac is an IoC container of the new age with all of it's inherent functional programming support. It also takes a different approach on managing lifetime than the others. Autofac is still very new, but it pushes the bar on what is possible with IoC.
Ninject I have heard is more bare bones with a less is more approach (heard not experienced).
The biggest discriminator of Unity is: it's from and supported by Microsoft (p&p). Unity has very good performance, and great documentation. It is also highly configurable. It doesn't have all the bells and whistles of say Castle / Structure Map.
So in summary, it really depends on what is important to you. I would agree with others on going and evaluating and seeing which one fits. The nice thing is you have a nice selection of donuts rather than just having to have a jelly one.
Autofac. https://github.com/autofac/Autofac It is really fast and pretty good. Here is a link with comparisons (made after Ninject fixed a memory leak issue).
http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
Ninject is great. It seems really fast, but I haven't done any comparisons. I know Nate, the author, did some comparisons between Ninject and other DI frameworks and is looking for more ways to improve the speed of Ninject.
I've heard lots of people I respect say good things about StructureMap and CastleWindsor. Those, in my mind, are the big three to look at right now.
I use Simple Injector:
Simple Injector is an easy, flexible and fast dependency injection library that uses best practice to guide your solutions toward the pit of success.
I'm a huge fan of Castle. I love the facilities it also provides beyond the IoC Container story. It really simplfies using NHibernate, logging, AOP, etc. I also use Binsor for configuration with Boo and have really fallen in love with Boo as a language because of it.
I spent the better part of a day struggling without success to get the simplest Spring.NET example working. Could never figure out how to get it to find my assembly from the XML file. In about 2 hours, on the other hand, I was able to get Ninject working, including testing integration with both NUnit and MSTest.
I've used Spring.NET in the past and had great success with it. I never noticed any substantial overhead with it, though the project we used it on was fairly heavy on its own. It only took a little time reading through the documentation to get it set up.
I can recommend Ninject. It's incredibly fast and easy to use but only if you don't need XML configuration, else you should use Windsor.
The great thing about C# is that it is following a path beaten by years of Java developers before it. So, my advice, generally speaking when looking for tools of this nature, is to look for the solid Java answer and see if there exists a .NET adaptation yet.
So when it comes to DI (and there are so many options out there, this really is a matter of taste) is Spring.NET. Additionally, it's always wise to research the people behind projects. I have no issue suggesting SourceGear products for source control (outside of using them) because I have respect for Eric Sink. I have seen Mark Pollack speak and what can I say, the guy just gets it.
In the end, there are a lot of DI frameworks and your best bet is to do some sample projects with a few of them and make an educated choice.
Good luck!
I think a good place to start is with Ninject, it is new and has taken into account alot of fine tuning and is really fast. Nate, the developer, really has a great site and great support.
Spring.Net is quite solid, but the documentation took some time to wade through. Autofac is good, and while .Net 2.0 is supported, you need VS 2008 to compile it, or else use the command line to build your app.
Related
I have been working on a Plugin based application in C#. Stumbled across Managed Extensibility Framework (MEF) but this seems to be obsolete and support is dropped off Prism and other Frameworks.
Are there any alternatives to MEF for .NET Framework? A lot of information around plugins is rather dated and old.
Thanks
MEF is NOT a Dependency Injection Container and for that reason it has been removed. So where to look?
The Unity Container (not to be confused with the Unity game development framework), has long been a very popular container for Prism developers, and is what Brian has used for years.
DryIoc has been a very popular and extremely fast alternative for the last several years and has converted many long term Unity fans because of it's performance and great API's.
Ninject is still supported for the moment for WPF. That said this could change in the future. The project is showing signs of being dead. They haven't had a release in over 2 years, it's not particularly fast, or widely used by Prism Developers.
BYOC (Bring your own container)... Prism 7 introduced a complete abstraction for Dependency Injection. This means that if there is a container that you would like to use, you can implement the IContainerExtension for the container you want and bring that into your project. NOTE for WPF development you would still need to tie that container into the ServiceLocator currently used by WPF. You can read more on that from this blog post on Using "Unsupported" DI Containers
Are there any alternatives to MEF for .NET Framework?
MEF is perfectly fine as plugin framework, no need to look somewhere else.
But you shouldn't also use it as dependency injection container (see Dan's answer).
Is it possible to use Spring.net on WP7? Would you recommend others DI/IoC-Containers for WP7 and why?
As far as I know, Spring's IoC won't run on WP7 since WP7 has limited runtime libraries. Spring depends on things that just don't exist in the WP7 world.
One that I use, and can recommend is MicroIoC. It's small, simple to integrate, lightweight, and works great on WP7.
Alternative IoC container implementations for WP7 include:
Ninject
SimpleContainer from Caliburn.Micro.
MicroIoC
Funq by Clarius Consulting
OpenNetCF.IoC
I have had good success with TinyIoC https://github.com/grumpydev/TinyIoC
Is really simple, just include a single C# file in your solution and you're good to go! It also features an Autoregister function which maps interfaces to their implementation (given you have only one implementation) and classes automatically.
Also using TinyMessenger for loosely coupled messages between your presentation layer and business logics (say if you're using MVVM or some other presentation pattern).
I've heard lots of good things about Ninject (https://github.com/ninject/ninject) on WP7 - but not used it myself
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Which .NET Dependency Injection frameworks are worth looking into?
Hi,
As a new kid in the C#/.NET block just moved in from Java neighbourhood, I am looking for options in Dependency Injection/IoC frameworks for .NET/C#.
From Scott Hanselman's blog post few years ago I got a fairly long list of DI frameworks, but there was really not enough information to go with beyond the list itself (plus a license and a version number) to make any semi-intelligent choice. Nor have I developed a ghestalt of the relative popularity (and thus the community support available) for any of these. And the list itself dates from 2008, which makes it a bit outdated, so I would like to ask kindly SO community for help on this matter.
Please list (or vote for) your favourite DI framework, adding a link to framework official website and please be so kind as to provide some reasoning for helping me and others developers like me to make a choice.
A code sample snippets for declaring and injecting dependencies would be of great help as well.
NB: Please restrict yourselves to one entry per response please, to keep it simple and objective.
I have used Ninject before and got on well with it. There are code samples on the front page of the website.
http://ninject.org/
Edit:
Ninject also supports MVC
Of those I have tried, I like Unity best by far. Easy to use, and feature rich. A note is that it's not supported if you are developing for Windows Phone 7.
Of the list I've tried Unity, StructureMap and Autofac.
I perfer StructureMap, I think it's the most straightforward and easiest to use. (didn't spend much time with Autofac tho since was just messing in my own time)
You could also use MEF, but be aware that MEF is not only for this purpose. Mostly MEF is a little oversized for normal DI scenarios, but very usefull if you intent to develop a extendible app.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to try using an DI/IoC framework for the first time in a small-ish but growing project, and I don't want to disturb the project much by introducing bulky dependencies. The project itself is partly intended to be used as a library in other projects, and I don't want to trouble users with managing extra dependencies. It's also a matter of taste--I feel the size of a component should be proportional to the amount of services that I actually need. I hate to incorporate a bulky component with dependencies of its own, only to use a small part of it.
So, for .NET, is there a small DI/IoC framework that compiles to a single DLL with no dependencies other than standard libraries, that (if necessary) could be directly embedded in the assembly that uses it, and that emphasizes code-based/fluent (as opposed to XML) wiring? It must not require .NET framework 4.0.
I feel much the same as you do about IOC frameworks. I use IOC all the time, I just don't see the need for a Framework much.
Having said that, the one I'd use if I were to pick one up would be AutoFac
It's simple, easy to grasp, and feels lightweight.
I'd also suggest in addition to NInject that you look at Microsoft's DI Framework, Unity.
Any framework that you will introduce will eventually become a dependency of your app. Also, people have varied definitions of what lightweight is. Take a look at Unity, or StructureMap or Castle Windsor as they tend to be more popular. Scott Hanselman has a whole list, here. Take your pick.
Take a look at Ninject.
Try StructureMap.
The core StructureMap.dll is pretty small.
There are examples on the web about writing your own container, although they are very basic and would lack features provided by a more robust framework.
I work with a rather large system and we've manually injected everything. We make use of the abstract factory pattern to tidy up most of the injection/wiring and it's worked out fine.
DI Frameworks are plentiful. Before taking on an extra external dependency, take some time to consider if applying a different/new pattern would solve your problems.
edit: (possibly biased/unjust) Reasons I haven't used a DI framework:
If you use a DI framework, you have to ship the DI framework with your software. This can be a show stopper for some, and others might have to argue the merits of the extra dependency.
You still have to build constructors to take dependencies
And you still have to tell (or at least hint) at the DI framework what to use. The only major difference is your using the DI factory rather than your own.
As for building that factory, most refactoring tools can do 90% of the work for you with very few keystrokes.
When the .net 2.0 framework first came out, the provider model was all the rage. 2.0 even shipped with a bunch of default providers (Membership, sitemap, role). Since the release of 2.0, the hype has died down, and whilst I still use providers day to day, it seems to get far less press.
I was wondering if this is because people are using something other than providers and they've been superseded, or is it simply because the take up wasn't as big as other IoC methods?
It actually hasn't died down. DI is still big. There are many DI frameworks out there to choose from. Yes, it's not hard-baked into every part framework like it should absolutely be, but its still a very good practice to follow. For instance, I was using the P&P's custom application blocks to do DI. Until they ditched it for Unity. Now I'm using unity.
A lightweight DI framework is a good idea for any large extensible application.
I think that as these tools become more standard within .NET the hype around them becomes less, but their use does not. Certainly the Membership and role providers are very important to our new application that we are developing and will save us significant amounts of code.
Microsoft Patterns and Practices is the birthplace of tools like the Enterprise Library, which is heavily involved with the provider patterns (particularly with membership) in regards to the Security Applicaiton block and the model appears to be used throughout the blocks.