Unfortunately I've only had time to do some Prism, although MEF seems to be the way to go. First of all it is a general framework, not limited to WPF/Silverlight and secondly it is used in the new Visual Studio 2010 release. What is amazing is that both frameworks come as freely available opensource.
Ok, back on Prism. The concepts are simple enough, although it takes a while to "get" the way to work with them. Basically you start with:
- a Bootstrapper class - it initializes the Shell and the Catalog
- a Shell - a visual frame where all the modules will be shown
- a Module Catalog - a class that determines which modules will be loaded
- an Inversion of Control Container - class that will determine, through Reflection usually, how to initialize the classes and what parameters they receive
- a RegionManager - class that will connect views with Regions, empty placeholders where views are supposed to be shown
- an EventAggregator - a class that is used to publish events or subscribe to events without referencing the objects that need to do that
Easy right? I don't even need to say more. But just in case you don't have a four digit IQ, better watch this four part video walkthrough:
Creating a modular application using Prism V2 - part 1
Creating a modular application using Prism V2 - part 2
Creating a modular application using Prism V2 - part 3
Creating a modular application using Prism V2 - part 4.
I did try to take the WPF Hands on Labs project and mold it with Prism and it partially worked. The problem I had was with the navigation controls. These work as a web application, where you call the XAML and it has to be a file somewhere, and you have events for the calling and returning from those "pages". I could find no way to encapsulate them so I could build no modules out of them and the whole thing collapsed.
So, for a quick walkthrough on using Prism with WPF.
Creating the core:
- create a new WPF application project
- reference the Prism libraries
- create the Bootstrapper class by inheriting UnityBottstrapper that will determine the Shell (a WPF window class) and set it as the application MainWindow, as well as create the type of ModuleCatalog (either take a default one or inherit one from IModuleCatalog) you want
- create the layout of the Shell and add region names to the controls you want to host the loaded modules (example <ContentControl Grid.Row="0" Margin="2" Regions:RegionManager.RegionName="SearchRegion"/>
Creating a module:
- create a new library project
- add a class that inherits IModule
- the constructor of the IModule can have different parameters, like an IRegionManager, an IUnityContainer, an IEventAggregator and any other types that have been registered in the container (I know it hasn't been initialized in the core, the catalog takes care of that). The IoC container will make sure the parameters are instantiated and passed to the module
- register views with regions and any additional types with the IoC container in the Initialize method of the module
- create view classes - WPF controls that have nothing except the graphical layout. Any value displayed, any command bound, any color and any style are bound to the default DataContext. The views will receive a view model class as a constructor parameter which they will set as their DataContext
- create the view model classes - they also can have any types in the contructor as long as they are registered with the IoC container, stuff like the eventAggregator or a data service or other class that provides the data in the view model.
- provide all the information needed in the view as public properties in the view model so that they can be bound
- subscribe or publish events with the event aggregator
As you can see, most of the work is done by the modules, as it should be. They are both communicating and displaying data using the event aggregator and the binding mechanisms of WPF. There are some differences between how WPF and Silverlight approach some issues. The Prism library brings some classes to complement the subset of functionality in Silverlight that are not needed in WPF. However, one can still use those for WPF applications, making a transition from WPF to Silverlight or a mixed project more easily maintained.
The video walkthrough (as well as my own text summary) are based on the rather new Model-View-ViewModel pattern, which many people call a flavour of MVC. It was created specifically for WPF/Silverlight in order to separate behaviour from user interface.
Expect more on this as soon as I unravel it myself.