MEF, MVVMLight and Silverlight…Oh My!

Well, it is the last day of 2009 and I am posting my last coding post of the year.  Nothing like waiting until the last day of the year to complete my goal of three substantial coding post before the end of the year.  In the coming days I will be putting a post together with my goals for 2010.  Stay tuned!

After reading posts by Glen Block and Shawn Wildermuth I have decided to try and build an application in Silverlight 4 using MEF and MVVMLight with a little bit of RIA Services thrown in for good measure.  I liked the way that Shawn structured his projects so I am going to follow that structure.  This application is not going to be ground breaking, it is more to get me comfortable using MEF and take MVVMLight for a spin.  These are technologies I hope to use in an upcoming project at work so I needed to get up to speed fast.  I believe that this project has succeeded in getting me the knowledge needed to complete my project at work.

Here is a list of the technologies I used:

• Silverlight 4
• MEF
• WCF RIA Services
• MVVMLight
• Chinook Database (To change from the standard demo databases)

As I stated before my goal was not to build a groundbreaking application but to test drive some frameworks so see if they were going to satisfy my needs.  Here is a list of some of those needs:

• Common Controls/Layout Across Apps
• Rapid Development
• Separation Of Concerns
• Maintainability

Common Controls and Layout

My company is developing an application this divided into modules.  Each module contains separate Silverlight applications.  The goal is to have a common layout and to utilize set of common controls.  This is where MEF comes in.  The layout consists of a menu area, a content area, a toolbar area and an information panel.  In my demo application I was able to create a common project to be shared across applications using MEF to provide the content.

   1: public partial class LayoutFrame : UserControl

   2:     {

   3:         [ImportMany]

   4:         public IContentList[] ContentLists { get; set; }

   5:  

   6:         [ImportMany]

   7:         public IDetailedList[] DetailLists { get; set; }

I facilitate this by creating interfaces in a common project that corresponds with areas in the layout.  Right now there is nothing to implement in these interfaces but I could see some in the future. 

Now all I have to do is have my view implement that interface and Export it….

   1: [Export(typeof(IDetailedList))]

   2: public partial class AlbumListView : UserControl, IDetailedList

   3: {

   4: ...

   5: }

Add the Layout control to the MainPage.Xaml…

   1: <cc:LayoutFrame />

Through the power of MEF my Views are laid out the way I want them even though the Layout control is in one dll and he Views are in another.  I can see my common controls living in that same common dll as the layout and getting the content from a ViewModel in my application.  I came up with this pattern from Glen’s demo.  I am not going (at this time) as far a having separate packages like Glen did but the concepts are the same.

Rapid Development

The ability to reuse these common controls and layouts will allow me to build out multiple modules more quickly.  All I have to do is build out the views and view models, wire them up to be picked up by the parts, and build out the back end using WCF RIA Services. Each application (module) will have its own RIA Services and  model (minimal overlap between modules).   There are business services already in place servicing the current UI implementation that I will reuse to increase the productivity of the Silverlight UI.  I will wrap those service with a custom RIA Sevice Context.  This will allow me to spend most of my time developing the views and view models.

Separation Of Concerns

One of the goals of my project is to keep the code clean by separating the concerns (the UI from the business logic).  To do this I decided to use MVVM.  This seems to be the pattern that community is embracing to develop Silverlight applications.  It satisfies my goal of keeping the code pretty clean.  One of the challenges of MVVM is cross View communications.  How do you get one part to talk to another part with out tightly coupling them.  That is where a framework like MVVMLight comes in (Thanks Shawn for the demo).

I used MVVMLight’s Message object to broadcast events…

   1: _artistSelected = new RelayCommand<Artist>(a => Messenger.Default.Send<Artist>(a, "AlbumListViewModel"));

Parts that are interested in events can subscribe…

   1: Messenger.Default.Register<Artist>(this, "AlbumListViewModel",

   2:    a =>

   3:    {

   4:        GetAlbumByArtist(a.Name);

   5:    });

   6:    }

I still have a little more research to do with the MVVMLight framework but my initial playing around has helped. 

Maintainability

MEF and MVVM will go along way to making my applications maintainable and also extendible.  The separation of concerns will allow me to change and add functionality without having to change my common layout, localizing changes to their respective modules.  The  flipside is also true, if I want to change the layout behavior I can do it in one place.  As long as I don’t mess with the MEF tags things should still work

Conclusion

In this post I touched on only a few things that I will need for my application at work.  In my demo code I did not address the Blendibility of my application.  In fact I did not address an UI candy.  I hope to build on this demo in future post to continue building it out.  I would like to thanks Glen Block for giving me the inspiration (and the framework) to compartmentalize my application.  I would also like to thank Shawn Wildermuth for giving me my initial project structure and pointing me to MVVMLight. 

Hope everyone has a safe and Happy New Year!  Talk to you next year.

You can get the code here.