We have been doing extensive development using Silverlight, and have run into some barriers with the design of the application we are working on. Some of the issues we were able to mitigate with MVVM pattern. However, as the app has become more complex, dependencies have crept in between the viewmodels and the parent application.We are also running into trouble managing commands and events associated with the application - how do you have several components subscribe to the same event set without having to connect viewmodels together?

The application's Xap file has also grown to be fairly large, and it will be necessary to split the application up into separate chunks that are loaded only when required. Our current structure will not allow this.

Upon doing research into how to address these issues, I discovered the Prism framework from the Microsoft Patterns and Practices group. This appeared to be a great way to address a number of the issues.

Prism is a framework for composing applications from separate modules. It contains an approach for injecting components into others using the Unity framework (also a patterns and practices framework) to eliminate dependencies. It also has a very nice looking commanding approach implemented through an event aggregator publish/subscribe mechanism.

However, during reading through commentary on Prism, I also found the Managed Extendability Framework, from a different part of Microsoft which looked initially like it was a competing approach to solve similar issues.

Microsoft often does things like this (take the whole Linq/ Linq-SQL/Ado.net entity framework/Windows Communication foundation maze as an example...) in which they come out with several almost the same but not completely technology bits that overlap. Inevitably one of the approaches will be adopted at the expense of the other, which forces developers who adopted the wrong one to refactor to the winner.


This meant more research into the details of the frameworks. There has been a large amount of discussion about the two frameworks and what roles they play. It looks like that while there is overlap, they do address slightly different issues.

MEF appears to be the 'lower level' framework and allows each component to 'import' things they need. Each component is marked with 'export' to mark things they provide- mef goes through the apps and matches them up. In this way, you can create components that are loosely coupled that assemble themselves at run time.

So it is essentially the 'glue' (or duct tape in Canadian terms) that ties components together instead of using tightly coupled approach.

Prism has a similar concept for eliminating component coupling, but instead uses Unity (a Patterns and Practices dependency injection framework I think) for this purpose.

It then goes on to add guidance and tools for building modules, commands, and binding modules and commands to make an overall application. So Prism is more focused on the user interface concern side of the equation, where MEF operates at the component level.

In fact, MEF was included in .net 4.0 and sivlerlight 4.0, which means that its approach 'won out' in terms of what it does over the the Unity approach used in Prism. It looks like for Prism release 4, the Prism team are refactoring the framework to use MEF.

So - it looks like what we can do is use MEF to glue the components together, then use Prism to handle the user interface composition aspect via the modules and event aggregator.

Its a bit frustrating having to figure out two separate (for now) frameworks to accomplish our goals, and it would be nice if the different bits of Microsoft communicated better on these sorts of things, but at least I found out about the path of this before committing to fully using one approach.

Here are some additional resources: