MEF and Prism, to be or not to be.

Now to the question, what is the story on Prism and MEF? I am getting asked this now several times a day, more so than the IoC question.

I am happy to say we’re working with p&p to come up with a good answer.

Note: This is still a work-in-progress, but here’s the thinking on this so far.

There is some obvious overlap but also a clear delineation. In particular when it comes to UI composition. MEF can be used for UI composition for sure, however it doesn’t have specific UI composition bits like RegionManager, Composite Commands, EventAggregator. Something like EventAgg will come in the future, but it is highly unlikely we will ever deliver some of the Prism UI-specific bits as part of MEF. That could change, but at least today that is the case.

In general though here are the differences.

  • First, MEF is in the platform as part of SL4/FX4.
  • Second, MEF is a general UI agnostic composition technology while Prism is specific for UI composition. MEF also extends beyond composite applications to general extensibility / plugin models.
  • Third, Prism and MEF can work together.

There are two primary use cases we hear from customers who want to use MEF and Prism together.

  1. Use Prism with MEF as an add-on for extensibility. That is make modules extensible through MEF.  You can think of this as the “Two worlds in harmony” solution. Your core architecture rests on Prism’s modularity / and an IoC Container and sits side by side with MEF.
  2. Use MEF primarily for modularity, and pull in Prism bits for UI composition.  In this model, your core architecutre sits on top of MEF, with MEF replacing the services of your IoC.

Note: You can also use MEF for some aspects of UI composition, particularly for pull-style regions which import their UI elements.

The first angle is primarily for customers who have existing applications that use Prism and want to use MEF. The second is for customers who are building new apps in SL4/FX4, that want to use MEF for providing the foundation, and pull in CAL libraries where appropriate.  I think both make equal sense depending on customer needs.

In terms of which to use when, my advice is it depends on your situation.

  • If you are already committed to Prism, stick with it. There will be guidance coming for integrating MEF and Prism in Prism 4.
  • If you are starting fresh (and you are choosing to use MEF) then you may to use MEF for modularity, and general aspects of your composite app and pull in Prism pieces where appropriate.
This entry was posted in MEF, prism. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://wizardsofsmart.net/ Ryan Riley

    I agree with Rob and Omer. MEF composing a ViewModel tree and then automatically composing its views is a huge win. I also agree with Omer in that I think Rx will eventually replace a lot of EventAggregator implementations. While I can’t think of anything off the top of my head, would MEF be able to compose Observables from Rx?

  • http://blogs.microsoft.co.il/blogs/bnaya/ Bnaya Eshet

    I prefer to use pure MEF for the extensibility model and take the good bits like the event aggregator from Prism

    MEF become the .NET standard for extensibility, and i believe that P&P should redesign the UI framework upon that standard

    MEF is simple to use and easily target dynamic scenarion like on the fly compsition

    so i vote for MEF with new design of UI framework

  • Omer Mor

    An even more interesting story would be about MEF + Prism + Rx (Reactive Extensions) !

  • http://www.caliburnproject.org Rob Eisenberg

    Glenn, you have missed a very significant usage of MEF IMO. Use MEF as a way to compose View Models. With the proper architecture, the composition of View Models *causes* the composition of views. It makes life oh so fine :)

  • Oleg

    Hello,

    At PDC talk you mentioned (if my memory serves me right) that there are five main ways MEF/Prism can collaborate.

    Could you tell little more on what they are?