“MEF in 2 hours or less”, I am all for it.

Some posts titles just really grab you. I couldn’t help but think about one of those annoying ads in the back of magazine when I saw this post from Ayende. In actuality the article is more of a “How I can implement what I need from MEF in 2 hours” however that’s not as provocative 🙂

The main point Ayende makes in the article is that folks talk about specific features in MEF like dynamic discovery and lazy loading as big deals, and he can implement something similar in a few hours. As I mentioned in the comments, I think Ayende is over generalizing on exactly what capabilities MEF actually provides, but I have no problem with that statement, just as I had no issue with Jeremy saying “Build your own CAB”. I went on to say (paraphrasing) “MEF is not built for you, it’s for the ecosystem”.

What I mean by that is this, MEF is designed for supporting a rich ecosystem of extenders, it establishes a standard for extensibility that crosses application boundaries. If you are a third-party extending an application built on MEF, you just need to speak the language. You can walk up to any application that speaks that language and you are golden. Eclipse / OSGI is a prime example of this (not talking about the Experience but the extensibility). Visual Studio’s Editor in 2010 is another prime example.

With MEF we’re saying you don’t have to be Eclipse / Visual Studio to provide the same type of experience. With MEF you can get off the ground with a few keystrokes, and without reading a 200 page manual. Of course that just gets you in the door, and as you scale up to use more advanced features MEF get’s more complex in fact, if you get to the Primitives you almost need to be a rocket scientist. However, you have a dial. If all you want to start with is using MEF for loading a small collection of plugins, you can do that with ease. Over time you can scale up according to your needs. As you scale you may find many of those features that you may not need today are a welcome addition.

Now back to Ayende’s comment, if you are not using MEF for it’s ecosystem enabling capabilities, and you do not find the features it provides adequate, then feel free to NOT use it. Don’t worry, we’re not going to send the MEF police to your door! (Though don’t be surprised if I ping you personally over IM 🙂 )

I am not saying that to drive you away from MEF, I am saying that saying NO is a valid option if it doesn’t meet your needs, and you can find/create something that does. If it does however meet your needs, saying no “just because” is silly.

I’ll close with this statement, there’s much more to MEF than meets the eye. I advise taking it for a ride before you discard it.

Comments (4)

  1. Its funny u say that, because that is the exact feeling I got when I read that post and after yet another "Entity Framework sucks NHibernate is awesome post".


    After having a Silverlight blog for over 1.5 years, I know that controversy and "sexy titles" lead to traffic.  The articles I spend 2-3 days writing with source code get little traffic, but a Flash vs Silverlight…watch out 🙂


    Onto the subject of MEF/IoC/Prism/can’t I just do this myself better….

    My experience as an architect is WHY.  Some people LOVE to get into "plumbing code" and write this stuff and get into micro-optimization and "best practice semantics" arguing whether attribute-decoration is better versus fluent APIs.  To those devs/architects more power to them.  However, I subscribe to the Juwal Lowy philosophy when he gives his WCF talks…about writing less plumbing code and delivering more features in your software.


    My personal opinion on MEF was turned when I heard your interview on a podcast a couple months ago before the PDC 2009 announcements.  It felt like there was more "Microsoft chatter" going on about MEF/Commanding than Prism.

    I think you guys (Microsoft) just need to do a better job selling MEF.  The hello world example is nice, but whats next?  Some things I am working on that would translate well into "MEF videos" would be:

    – showing how MEF allows you to build a Silverlight SaaS application with Level 4 maturity (configurable, multi-tenant features implemented with MEF)

    – contrasting MEF plug-in model with web part model.  For example our 2 Silverlight solutions composed of components work standalone as entire apps and "parts" of them work standalone as Silverlight web parts.  (Goes into the whole architecture of parts of MEF).

    I watched Mike Taulty’s videos and they are pretty detailed and so far the most "complete" MEF resourse I have found.  When you say, you don’t need a 200 page manual to get started with MEF…I disagree.  I think with all the features that MEF brings…the "best practice" items appear to be forming (at least in my head):

    – using lazy loading import parts with dynamically loaded assemblies to minimize size, memory pressure and optimize load times.

  2. Mike Greenway says:

    well intented, well said.

    I was going to use MEF but now I’m going to use it twice.

    thanks and have fun

  3. Joe Abraham says:

    Glenn – Congratulations on an awesome extensibility framework.

  4. sarafuddin says:

    I have recently been digging into MEF and hit into Ayende's post. It was a bit propelling but i was sure i am taking the right path "The way of the MEF". And now i hit into your post.. what more can i say.. others comments have made the thoughts in my head already visible.

    But i do prefer something like Bart said "showing how MEF allows you to build a Silverlight SaaS application with Level 4 maturity "

    Saraf Talukder