First experiments using MEF, MVVM and Silverlight 4 Beta

Note – this is a multi part post:

MEF (Managed Extensibility Framework) is a new library available in Silverlight 4 Beta which permits to build applications that can be incrementally extended in a declarative way using three simple concepts (read this post by Glenn Block for more infos):

  • Export an object;
  • Import it;
  • Compose it.

Mixing MEF and commanding, Silverlight has now a great support for structuring projects using a ViewModel approach, so I decided to use these new characteristics to build a simple solution.

Given an existing project, I added a ViewModel class implementing INotifyPropertyChanged:

    public class MainPageViewModel : ViewModelBase
        public MainPageViewModel()
            aViewModelProperty = "This is the content of a ViewModel property";

            aSampleCommand = new AViewCommand();

        public string aViewModelProperty { get; set; }

        public ICommand aSampleCommand {get; set;}

The problem I’ve solved using MEF is the binding of the DataContext property of the UserControl to a ViewModel class instance, so I’ve exported it using the MEF [Export] attribute.

The [Import] attribute and the PartInitializer.SatisfyImports(this);  are then used in the code behind of the xaml view in order to import and compose the ViewModel instance with the DataContext:

        public MainPage()

            this.DataContext = mainPageViewModel;

        public object mainPageViewModel { get; set; }

And this is the result:


As usually the source code is available for download here.

Happy Silverlighting!

20 thoughts on “First experiments using MEF, MVVM and Silverlight 4 Beta”

  1. Can you elaborate on why MEF is needed to to data binding? I thought one of the new features of the BING map control was data bound info. Which I saw the PDC demo using collections…

  2. @DrYSG @David
    I’ve tried this approach to marry the view with the VW using a declarative style permitted by MEF (example: multiple ViewModels for a same View)

  3. Davide nice post. Just out of curiousity, why are you using a string import for the VM as opposed to an actual type.

    Are you expecting to reuse the VMs across multiple types that have no common interface? In general we recommend using types as the contract rather than loose strings with strings being the exception to the rule.

    Why not do this, which uses the VM type as the export/import?

    [Export] //will export MainPageViewModel
    public class MainPageViewModel {


    public class MainPage {
    public MainPageViewModel mainPageViewModel { get; set; }

  4. Note, you can also do this if you had the need, though ViewModels do not usually need to be mocked. However just for illustration…..

    [Export] //will export MainPageViewModel
    public class MainPageViewModel : IMainPageViewModel {


    public class MainPage {
    public IMainPageViewModel mainPageViewModel { get; set; }

  5. Hi Glenn, thanks for the suggestions! Yes, my idea was to marry the view with the viewmodel using a declarative style without any “using” clause in the view, so I had to define the VM property as “object” type.
    I agree with you for the usage of types in contracts instead of strings, in this case however the “object” type declaration has forced me to use them.
    I’ll further investigate this approach, thanks again!! 🙂

  6. Hi, MEF looks nice. Is it possible to put extensions in seperate dll’s?
    1. Put the modelview in a seperate dll, which is then easy to update.
    2. Using seperate dll’s, on can let MEF import new features. This is out of the modelview context, just generaly speaking.



Leave a Reply

Your email address will not be published. Required fields are marked *