8

Possible Duplicate:
How do the major C# DI/IoC frameworks compare?

There being so many DI containers, I feel kind of lost. I'm new to the DI pattern.

I'm reading the book Dependency Injection in .NET and I've found DI to be incredible useful in improving a code base, making it loose coupled and more testable.

I now want to introduce a DI container for my dummy project, but there are just so many to choose from.

How am I supposed to choose between Castle Windsor, Unity, StructureMap, Spring.NET, Autofac, Ninject, Funq, LinFu, etc, etc?

I guess a coherent take would be to "just pick one" and start using it (since I figure they're pretty easily interchangeable, specially in the early stages), but I would like to make a more informed decision.

Community
  • 1
  • 1
bevacqua
  • 47,502
  • 56
  • 171
  • 285
  • Whatever you do, do not pick Funq, because it doesn't support automatic constructor injection, which basically disqualified it from use on any real project, or in fact disqualifies it as a real DI container. – Steven Feb 25 '12 at 02:07

6 Answers6

5

This is like buying a car. You might like a Toyota, but it's just 2.5L engine. You might like Ferrari, but it's too red. You might like Mazda, but your boss doesn't allow you to drive it. You might like Hummer, but then your colleagues would laugh at you. Mix the manufacturers to your taste, there's always going to be something missing for somebody or at some different moment.

My take is - first and foremost, DI is usually better then not having DI. Pick anything and you'll be better off. I'd pick something that:

  • Has good support in community (so you can get answers)
  • Has a good backing company behind it (so you don't get to rewrite your code when it goes bust)
  • Feels good to you (so you don't swear in front of the kids, not cool)
  • Is not an overkill for the project
  • Is not just DI, but offers an ecosystem of things that will reduce the time you spend on tasks that you know you can do, just not right now - and then you can focus on things that matter
  • Is used by a lot of people (so you know that many parts are also tested in real life and bugs filled)
  • Isn't 5 years old (such as that documentation says it is supported on Windows 98 or something)

My 2 cents - http://www.springframework.net/. I mean, their documentation contents page is like 20 pages long...

Or you just might want to look at some more answers to a similar question:

Community
  • 1
  • 1
icyrock.com
  • 27,952
  • 4
  • 66
  • 85
2

You can start with the builtin DependencyResolver in MVC3. Later you can easily upgrade to Enterprise Library Unity DI.

Brad Wilson had mentioned a series of posts on How to use DI in MVC3.

Manas
  • 2,534
  • 20
  • 21
0

My stance is, look at a few - you got the excellent "Dependency Injection in .NET" book already (to that list I would add Ninject, which unfortunately is not covered in the book) - and pick one of them that you understand the best and like the syntax. To get started with advanced features are not really important, just that you do start.

Once you have a IoC container, replacing it should be mostly trivial since all your changes will be in one spot - the aggregate root - and not spread out all over your code base. Using an IoC container will also force you to design for dependency injection if you have not already, that will be the much bigger impact on your projects.

BrokenGlass
  • 158,293
  • 28
  • 286
  • 335
0

I've been using Ninject and Unity. When you add Unity MVC to Unity, then the code reminds me of the Ninject code.

Both are very easy to implement. Both allow substitution of being config file centric with a launcher class centricity.

I suggest create a 2 hour project, and implement it in each of the ioc di frameworks, and decide by experience which one you like. However, if you do this without looking at other features you may find that you missed something. So do look at periferal features, such as 3rd party support.

0

In addition to the other great comments - if you install the Unity.MVC3 package, just beware you have to use HierarchicalLifetimeManager if you want your objects disposed with each request. Its worked great but I think you'll find in most cases all the major ones are quite nice.

The question for you is to find one that fits into your environment. Some places allow open source, some dont and in those cases Unity wins out.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
-5

The most developed DI container for .NET is Managed Extensibility Framework (MEF) and I strongly recommend to use it. MEF is fast, easy and maintainable across the team together with a perfect learning curve.

Community
  • 1
  • 1
ogggre
  • 2,204
  • 1
  • 23
  • 19
  • 6
    *"The most developed DI container for .NET is MEF"* - that blanket statement is certainly not true at all – BrokenGlass Feb 25 '12 at 01:26
  • I just shared my experience and I've used a bunch of DI solutions before. Nevermind... – ogggre Feb 25 '12 at 01:28
  • 3
    MEF is not a DI container. MEF provides Plug and Play configuration on the top of a base implementation.( as the name suggest it is a extensibility framework not DI) – Manas Feb 25 '12 at 01:36
  • Isn't MEF the most recent of this sort of libraries, and not even a DI container? – bevacqua Feb 25 '12 at 01:45
  • @Manas, I have to agree with you. MEF is not a classical DI container with proxies and aspect orientation. Yes, it is more like magical plug and play tool. But nevertheless it rocks comparing to classical IoC and DI solutions due to its simplicity and clean design when it comes to the real-life use: just [Export] and [Import]. Done. And it does Dependency Injection. And it is a Container. So, I am sticking to my original answer: MEF is you friend – ogggre Feb 25 '12 at 01:54
  • Yes Oggre, We can resolve dependency using MEF ( get all the exported types and select the appropriate one based on current request).But this not an ideal way to do.Better use combinition of DI & MEF ,let them play their indivisual role. – Manas Feb 25 '12 at 02:08
  • 4
    -1 MEF is not a DI container at all. – Sebastian Weber Feb 25 '12 at 06:37
  • Sebastian, you just heard the buzz that MEF is not DI container. I say: it is, and you have nothing against it. It does the job in a much more productive way than a bunch of its overdesigned predecessors. Let's go by items: 1) MEF is container 2) MEF injects dependencies. 1 + 2 = DI container, at the very least. Enough said. – ogggre Feb 25 '12 at 06:59
  • 3
    @ogggre Even the developers of MEF don't claim it's a container. Its a plugin mechanism. You may be able to abuse it as a container. If you like to polute your code with attributes and whatnot. You can also use a hammer to drill a hole in a wall. – Sebastian Weber Feb 27 '12 at 08:21