MEF + Prism = Potential posibility?

Oct 23, 2009 at 2:33 PM
Edited Oct 23, 2009 at 2:40 PM

Hello,

Our company has been developing a modular framework (and concept) that could be used to build up many different specific desktop as well as SL applications. We've currently employed Prism as the kernel. Because MEF is presented as a part of .NET 4.0, we're looking for the possibility to use two excellent frameworks as the same time. Our approach is still at the initial stage, of course, we're going to share this experiment whenever the outcome is concrete.

As a member of both Prism and MEF projects, could you (Mr. Glenn Block) show us some possibilites to use MEF and Prism in combination or atleast correct our following personal points of view?

1) Prism and MEF nearly shares the same goal.

2) The smallest pluggable unit of Prism is Module, while it is quite open by MEF (ComposablePart is the MEF's first class citizen).

3) For the composition of UI Elements (Views), Prism could be preferable deal to its Region Concept. In contrast, MEF could be employed for the composition of Non-UI Elements (Models, Services, or ViewModels).

4) Both realize the IoC Concept.

5) Prism supports inter-module event-exchange mechanism (EventAggregator), while MEF does not.

 

Thank you so much

Steven

 

 

 

Oct 23, 2009 at 6:51 PM

Hi Steven

Good timing :-) We are working with p&p and looking into that very prospect. Right now you can get MEF and Prism to work together, but there is a bit of work you need to do if you want to rip Unity entirely. Basically you need to annotate the Prism services that you are planning to use with Exports and then have a custom bootstrapper which creates a MEF container, and MEF catalog. 

As you mention MEF's entire model is modular, thus the need for modules in the traditonal prism sense tends to vanish away. On the usage of MEF with Prism, you can do this today. Prism rests on providing a common service locator for it's services and such. You can find an implementation of a CSL adapter for MEF at CommonServiceLocator.codeplex.com, thus you can plug in MEF if you choose. There are also paths to integrating both MEF and Unity in those instances where that makes sense, particularly when there is existing infrastructure. I am planning a blog post with more on how / why one would do that.

Here's a few answers to your questions.

1. They certainly overlap, though Prism is focused primarily on the Composite UI, MEF is a more general mechanism for composition of components. Also MEF's discovery model makes it ideal for third-party extensibility scenarios, somethng was not a direct goal of Prism.

2. Agreed. The one big difference being that in the MEF world there is no explicit registration of the available set of components (parts) as is customary when you build modules in Prism. The need vanishes because all of the parts are individually discoverable.

3. Well that's an area that there is debate. Regions are one way to do UI composition. MEF actually favors a pull model where metadata can be used to determine what goes where. The advantage of pull models is they are more analyzable. However, you can certainly use regions with MEF.

4. Yes, Prism relies on some IoC mechanism to deliver it's services and such, this can be Unity, or MEF. Looking in general at IoC containers vs MEF, one of the primary differences is that with an IoC the host configures the known universe wheras with MEF we discover it dynamically at runtime. This fundamental difference has a direct impact on the APIs / usage of each.

5. Yes, MEF does not ship with anything out of the box, you can easily though use Prism's EA, Laurent Bugnion's Messenger in MVVM Light, or other existing eventing mechanisms with MEF. On the Prism EA side, you can even drop EA and just use the Prism event classes in the manner i described here: http://codebetter.com/blogs/glenn.block/archive/2009/02/23/event-aggregation-with-mef-with-and-without-eventaggregator.aspx

Steven, I'd love to know more about what led you down the path to use Prism, and what specific problems are you trying to address?

Thanks

Glenn

Oct 27, 2009 at 3:53 PM

Hi Glenn,

thank you so much for your answers!

Our company have currently developed a plug-in Silverlight application. We decided to down the path to use Prism since it was quite, at that time, the unique option that we were able to select. Of course, Prism does not support all things for developing a complete modular SL-application, but it atleats presents some suitable concepts for this purpose like dependency injection, unity container or event aggregator.

Due to the new requirements of company,  we need for the future a plug-in framework (that muss be a real meta-framework) that can be later employed to build up other specific stand-alone WPF desktop as well as Silverlight applications. We found out that Prism is now not enough. We need a new whole concept as well as must still take advantage of the legacy Prism App. Our first approach what I can reveal right now is somehow Software Factory with MEF and Prism (but maybe Prism will be later removed step by step).

We wish that in the very next time, we can hear something about the completely unique Modular Software Concept from your team or at least some showcases about how to use MEF with Prism most efficiently.

Cheers

Steven

 

@Glenn: I wonder about the future of Prism, will the Prism be terminated after the release of .NET Framework 4?

Oct 28, 2009 at 1:06 AM

Hi Steven,

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,

David Hill
patterns and practices

 

Dec 5, 2010 at 12:52 PM
Edited Apr 20, 2011 at 1:03 PM

.