After reading some stuff such as this: http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
I understand that MEF has some featcures that I will not find in an IoC, and that MEF has some IoC stuff that is probaboly not as advanced as some other IoC systems can offer.
I need the MEF stuff. Do I also need an IoC framework or would I be fine with what MEF has?
Asher
Depends on your requirements/existing code.
If you have an existing code infrastructure built on an IoC container, you can in fact combine these with MEF. Recently I've been building an ASP.NET MVC+MEF framework, and a couple of my readers have been asking how to integrate Unity with the MEF+MVC framework I have built. This turned out to be really easy, thanks to a project called the Common Services Locator.
The CSL project is designed to provide an abstraction over service location, so I can grab a CSL provider for Unity, wire it up with a custom ExportProvider and MEF automatically starts composing my IoC-driven parts.
This is one of the benefits of MEFs ExportProvider model, you can easily plug in any additional providers to start pulling exports from a variety of sources.
Last week I blogged about combining MEF+Unity (and also MEF+Autofac as another exmaple), and although my examples are geared up for ASP.NET MVC, the concept is the same for most other implementations.
If you have the option of building something fresh using MEF, you'll probably find that you won't need an IoC container, MEF can handle property injection, constructor injection, part lifetime management, and type resolution.
Let me know if you have any questions :)
An IoC follows a purpose.
MEF specially is good designed, if you want to have some sort of plugins in your system. or code that you do not trust to run properly (dont forget to handle exceptions).
but, it comes therefore with a overhead.
if you just want to do IoC, as it is a good design pattern for extensible and testable software, then i would recommend AutoFac, as it is from the same guy. more or less :-)
and, if you need both intentions. then use Both. as Matthew pointed out, you can use the CSL to abstract both. if wanted.
for plugins -> MEF
for your IoC -> an simple IoC
We use MEF as an IoC container and it is working for us.
That being said, you should take a look at this blog post by Glenn Block where he lists the shortcomings you might encounter: Should I use MEF for my general IoC needs?
I am using MEF for both extensibility and IoC in SoapBox Core. There's also an article on CodeProject called Building an Extensible Application with MEF, WPF, and MVVM describing how it works.
I was using the Provider Model for essentially "IOC" in web application before switching to AutoFac recently.
Basically my requirement is that I need to be able to "on-sell" applications, so any interfaces need to be abstracted. By using the Provider Model things tend to get messy. Using an IOC container (if you are already) makes more sense, and I can still meet my requirements of "on-selling" because the IOC container can be "reconfigured" to allow different implementations.
I think MEF would be the best solution if you want a clean code base because it has more conventions, so essentially people could drop components in a folder and not change any configuration to instigate changes. This is nice but possibly overkill for my scenario where a simple config override is sufficient.
Read more on my blog post - hopefully the blog will get some good comments about it too: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
