To add to Glenn's comments on Prism and MEF, and your question about the future of Prism:
MEF and Prism do not share the same goals, though they do overlap to some degree in certain areas. Prism is focused on providing guidance for building modular
composite applications for Silverlight and WPF and includes a range of patterns and features that work together to achieve that goal. We designed Prism so that you can use it all, or just the patterns and features that make sense for your application, and
so that you can extend it and build upon it.
For example, one of the patterns that Prism employs for component composition is Dependency Injection. Another is the concept of modularity – splitting an application up into coarse grained re-usable modules.
MEF overlaps somewhat with both of these areas… I’ll dig into those areas a little:
For Dependency Injection, Prism 2.0 leverages the ‘Unity’ DI container. Note however that Prism doesn’t actually depend on Unity. We use it in the quick-starts and in the reference implementation but Prism itself is independent of the actual
DI container implementation. Prism abstracts itself away from the DI container implementation using the Common Service Locator that Glenn mentioned. This allows other component composition strategies and DI containers to be easily plugged in. This means, as
Glenn said, MEF can very easily be used with Prism by using it to provide the component composition implementation behind the Common Service Locator interface. One of the key advantages of MEF is that you don’t need to explicitly register components
that can be composed, but other DI containers, including Unity, provide other advantages that you might want to take advantage of. We used to Common Service Locator to give you the freedom to choose an approach that best fits your application scenario.
In terms of modularity, it’s important to note that Prism modules are much coarser grained than what MEF considers a ‘module’ or a part. A module in Prism is more akin to a MEF Catalog. A Prism module can consist of multiple assemblies,
each containing multiple components (or parts). Prism provide some infrastructure for discovering, deploying and loading modules and for integrating the functionality that they contain into the Shell. MEF catalogs provide some of this functionality too, so
it’s possible to leverage MEF’s catalogs alongside Prism’s module management pieces.
In terms of UI composition – Model-View-ViewModel, Regions, etc – using Prism and MEF together provides a couple of interesting options. To implement the ViewModel pattern (or any other separated presentation pattern) you typically have to hookup
two or more components (View, ViewModel, Model, Presenter, etc) and so this is a component composition problem. In Prism 2.0 we used Unity and Dependency Injection to do this but MEF can also be used to do this too. We’ll be exploring the uses of MEF
for this scenario in Prism 3.0...
For Regions, Prism provides a number of strategies, including a pull strategy and a push strategy. These are both useful at different times and it’s not possible to recommend one over the other for all scenarios. Prism gives you the option to choose
the strategy that fits your situation best. In Prism 3.0 we’ll be looking at maybe using MEF to help with this scenario too.
So, to recap – using Prism and MEF together provides a lot of interesting opportunities, but they don’t have the same goals so it’s not correct to think of MEF as replacing Prism. We’re planning on kicking off the development of Prism
3.0 early next year and we’ll be looking closely at how to leverage MEF and the other features in WPF 4.0 and Silverlight 4.0. It would be great to understand your requirements a little more so we can try and make sure that Prism 3.0 is closer to what
you need for your application.
Hope this helps,
patterns and practices