Does MEF eliminate the need for Prism modules?

Jun 18, 2010 at 5:12 PM

I've been looking at MEF and Prism. It seems to me that everything I can do with Prism modules can be done with MEF. Prism talks about modularity but can't I do just the same thing with MEF by putting my code into different projects and then using MEF to load up whichever project I'm working on?

What advantages would there be to using Prism modules?

Advice would be much appreciated,


Jun 18, 2010 at 7:36 PM
Edited Jun 18, 2010 at 7:37 PM Personally, I don't like the unityContainer in Prism and prefer MEFs dependency discovery. I will be making use of the Prism Event Aggregator though. P.S. Forum software is dumb - how do I insert a new line!?
Jun 19, 2010 at 2:04 AM
Edited Jun 20, 2010 at 5:49 PM

From a pure modularity perspective MEF is definitely up to the task. However using Prism is still orthagonal to MEF. Prism v4 ( is actually including a set quickstarts along with libraries for using MEF as the underlying modularity mechanism.

Beyond modularity there are several things Prism brings to the table which MEF does not.

  1. Prism includes a full set of guidance for building composite applications including quickstarts, samples and pattern guidance. This poinjt is very important to consider when you think of Prism and MEF. MEF is a framework and part of .NET itself. That in itself brings many benefits, but it is not guidance. Prism on the other hand is more of an end to end guidance experience for building composite UI applications.
  2. Prism includes the Event aggregator for firing pub/sub style messages as well as specific composite UI functionality such as Region Manager, and command / composite command infrastructure. You can also pull these specific library bits and use them along with MEF.

Below are a few links on this. Also I advise checking out the latest Prism drop to see how the two are being integrated.




Jun 19, 2010 at 3:35 AM
Edited Jun 19, 2010 at 6:18 AM

Thanks for the information and the links. I have a quick question.

Scenario 1: MEF Application with three class libraries called ModuleA, ModuleB and Module C.

Scenario 2: Prism Application with three modules contained within class libraries called ModuleA, ModuleB and Module C

Scenario 3: MEF / Prism Application with three modules contained within class libraries called ModuleA, ModuleB and Module C. Similar to the Modularity example in the Prism 4 samples

Am I correct in saying that using MEF in the first scenario I can still load my class libraries on demand and "when available" ?

What if any would be the advantage of my using modules with Prism in scenario 2 or scenario 3 ?



Jun 19, 2010 at 6:18 AM

Absolutely. If you look at the Prism Quickstart it is using MEF's underlying DeploymentCatalog to do the dynamic loading. Read more on that here: DeploymentCatalog allows on-demand downloading of catalogs that are deployed as separate XAPs.

The advantage of using Prism's module infrastructure (that is the MEF one) is you get something higher level out of the box that handles modularity concerns. It wraps MEF's underlying plumbing with some standard infrastructure for modularizing your apps, such as an IModule interface, standard metadata, a bootstrapper for initialization ,etc. You don't absolutely need Prism to do this, but you will end up building something similar though more targetted.