MEF and Ninject, which are the differences between them and what does it imply?

Question

Hi there,

I'm starting with the dependency injection matters, and even after read several articles about it... I still have a mess with MEF and Ninject.

The difference seems that MEF is not an IoC, and Ninject is. But... which conclusions does imply that? What MEF may do that Ninject cannot? and what Ninject may do that MEF cannot?

Cheers.

---

.: Valeriano Tórtola - MCPD 2.0:Windows Developer & Enterprise Applications :.: http://www.vtortola.net :.

Answer 1

It's more a matter of goals...

MEF is meant to be used as a dependency injection framework, and the plan is that MS is going to be including it directly in .NET 4, and it will be the main DI framework for things such as VS2010.  The goal here is to allow third parties to extend functionality in an existing application.

Ninject's geared for an as IoC platform - the goal here is to provide inversion of control throughout the application.

There is a lot of similarity between the two, although the means of using the two platforms is different.  MEF is an IoC container internally, but it is not really designed to be used that way - it really is designed as a way to permit extension of a complete application.  Ninject is really designed to build your application on IoC principles yourself, but probably is a bit more complex for handling extensions of your main application.

I would recommend looking at some of the samples of both, and decide what you like the best.  For the most part, it's personal preference.  IMO, the main benefits of one over the other are:

Ninject - More mature at this point, not changing as quickly.

MEF - Going to be core part of .NET 4, so won't require 3rd party libraries for extensions.  Very easy to use, and quite flexible.  In the long run, will probably be used by the most people commercially, since it's going to be embraced as part of the platform.

Answer 2

First of all, thanks for your explanation.

So, may I do the same things with both?

Cheers.

---

.: Valeriano Tórtola - MCPD 2.0:Windows Developer & Enterprise Applications :.: http://www.vtortola.net :.

Answer 3

You can do many of the same things with both.

Again, look at the goals - you can probably accomplish either goal with either option, but one will be easier.  What are you trying to do?

Answer 4

I'm just trying to understand the technical differences between them :P

Cheers.

---

.: Valeriano Tórtola - MCPD 2.0:Windows Developer & Enterprise Applications :.: http://www.vtortola.net :.

Answer 5

Ninject's big thing is their fluent API.  From a technical side (from what I remember), the main difference is in how the injection works.

In Ninject, you do something like: Bind<IWeapon>().To<Sword>();  This explicitly sets all of your IWeapon injection points to implementations of Sword.

MEF is a bit different, with MEF, you go through, and just add in the assemblies you want to match up, and it'll automatically pick based off the types.  Everything is flagged with [Import] and [Export], and MEF does the matching.  In that regard, it's a bit easier to use.  It handles IEnumerable<IType>, allowing you to pull across many different versions.  MEF also has a different mechanism for narrowing down what is matched across.

[Subjective stuff follows...]

Ninject seems to be better, up front, if you know you want completely control over every single injection point.  MEF is easier IMO to use if you're trying to extend.

My personal take was that I preferred MEF, mostly because it allowed me to not really get into exactly how things were injected (although you can go there).  You just say "inject here", and load your assemblies, then say "go", and it works.  Ninject projects seem to have a big central area where you're saying "put A into B, and A into C, and D into B, ....", since you're handling the injection yourself.

Answer 6

Thanks, I think I'm starting to have a clearer idea :)

---

.: Valeriano Tórtola - MCPD 2.0:Windows Developer & Enterprise Applications :.: http://www.vtortola.net :.