Strangelights

 

The MVVM Pattern Using F#

Published: 2010-11-21

The MVVM (Model View View Model) design pattern is a popular way to create WFP (or Silverlight or Windows Phone 7) applications.Despite the obscure name, the design pattern is surprisingly simple. Basically, the programmer creates a view model which is bound the the view (i.e. the xaml) via WFP binding model. Thanks the WPF’s two way bindings, the INotifyPropertyChanged interface and the ObservableCollection<T> there’s very little need for any other direct interactions between the view and the bound model.

I had the idea to use F# to implement the ViewModel, the object that exposes the values that xaml is bound to, when doing some work in Silverlight. To ensure a GUI remains responsive it’s important to take advantage of the asynchronous programming model when writing your view model. This means view models written in C#, or at least pre-C# 5.0, must make heavy use of continuation passing style which can make it difficult to co-ordinate many asynchronous calls. In F# we can use asynchronous workflows to tidy this up a bit. We’re going to show this by writing a small app that will connect to Yahoo! Finance download some stock data and present this in a DataGrid with a drop down list to select the company who’s stocks we’re interested in. Here’s the not very interesting GUI:

Obviously if we have a designer on the team and the blend package we can do a lot better than this.

A view model is class, which is declared in F# like this:

1. // A view model for a simple stock price history viewing app
2. type StockViewerViewModel() =

Each view model will need to implement the INotifyPropertyChanged interface. I chose to do this directly in my base class as I only have one view model, as each view model must implement this we’d normally put this in base class or similar. I also chose a simplistic implementation that requires each property to explicitly raise the the event when it’s being changed. There’s various ways we could implement this using reflection, so we don’t have to explicitly raise an event, but as this post isn’t really about this we’ll just do the simplest thing possibly.

 

1. // create an event object
2. let cecEvent = new Event<PropertyChangedEventHandler,PropertyChangedEventArgs>()
3. // implement the interface INotifyPropertyChanged
4. interface INotifyPropertyChanged with
5.     // PropertyChanged is raised each time a property changes,
6.     // it's INotifyPropertyChanged's only memeber
7.     [<CLIEvent>]
8.     member x.PropertyChanged = cecEvent.Publish
9.  
10. // this method provides a convient way of raising the PropertyChanged event
11. member x.TriggerPropertyChanged(name)=
12.     cecEvent.Trigger (x, new PropertyChangedEventArgs(name))

So, now we need to create and expose the the objects that will hold the data. This means adding the following member let bindings:

1. // indicates if the screen is busy or not
2. let mutable isBusy = true
3. // contains the currect company
4. let mutable selectedCompany = ""
5.  
6. // diction of company name * quote data
7. let dataDict = new Dictionary<string, ObservableCollection<Quote>>()
8. // list of companies to drive drop down
9. let companies = new ObservableCollection<string>()

Then exposing them using properties, note how we call the TriggerPropertyChanged each time a property is set:

Finally the fun part, loading the data into the objects exposed to the GUI:

Probably the thing worth noting about this snippet is that after the async calls we’ll be running on thread pool threads, this means interacting withe GUI from these threads would cause an exception. So we need to marchal back to the GUI thread. This is done by grabbing the synchronisation context (let syncContext = …) then call the Async.SwithcToContext method from within the workflow. I was pleasantly surprised to see there’s a nice MSDN example that show’s you how to do this.

And that’s it for the view model. All you have to do now is bind the view model to the xaml’s .DataContext property and call the OnLoaded method from the Loaded event that the xaml window exposes. Normally you’d hook the two together by doing something clever with an IoC container, but as it’s such a small example I chose to hook the two together directly.

I’ve prepared to VS solution files that show the work solution. One use a C# project to host the xaml file and writes just the view model in F#, the other just uses F# and has a small main function that explicitly loads the xaml file from the assemblies resources.

The C#/F# version can be found here.

The F# version can be found here.

Wrapping things up

Hopefully you’ve seen how it’s easy to use the powerful F# language to implement a view model to take care of a the domain and data access logic, while the GUI itself can be written in xaml and/or C#.