Category: Edgy coding

Microsoft recently dropped an MVVM Visual Studio project template for the WPF Futures release of the WPF Toolkit on Codeplex.  In giving the history the MVVM UI design pattern, the documentation states that “[t]he origins of this pattern are obscure,” making it perhaps the first cryptozoological design pattern, discovered somewhere in the deep jungles of the Expression Blend development team.

MVVM is peculiar for a variety of reasons but the chief is that it does not originate on Martin Fowler’s Bliki as do the MVP and Presentation Model patterns.  Instead it is a found pattern.  Another peculiarity of the MVVM is that, unlike PM or MVP, it is not technology independent.  It is specifically targeted at XAML-based technologies, WPF in particular, and consequently tends to be described in concrete terms rather than abstract principles.

For me this is a strength of the MVVM pattern, since we don’t have to keep going back to a canonical document to find out if we are implementing the pattern correctly.  In fact, for a long time, if you implemented a UI design pattern in WPF, you could pretty much be assured that you were using a variant of the MVVM.  After all, who is going to correct you?

Without a canonical pattern document, however, we are very dependent on example code to find out how other people are doing it.  Currently my two favorites are Josh Smith’s WPF example http://msdn.microsoft.com/en-us/magazine/dd419663.aspx and Shawn Wildermuth’s Silverlight 2 example http://msdn.microsoft.com/en-us/magazine/dd458800.aspx .  It is especially interesting to contrast these two examples since many implementation details found in Mr. Smith’s example code are either impossible to implement in Mr. Wildermuth’s Silverlight example or simply not implemented.

Two key differences are the way Views are associated with ViewModels and the way the ViewModel encapsulates behavior.

In associating Views with ViewModels, it is important to remember that there are always top level Views and dependent Views as well as top level ModelViews and dependent ModelViews. 

On the UI layer, a WPF Window type serves as a container for various WPF UserControl types.  In the MVVM ontology, both are considered to be Views.  Because the structure of a ViewModel is closely associated with the structure of its View (ViewModel is, after all, intended to mean the Model of the View), this container-dependent object structure must be mirrored in the structure of the ViewModel.  If there is a top level View, then there must also be a top level ViewModel.  The top level ViewModel must, in turn, serve up additional objects and collections that correlate with the UserControl Views contained by the top level Window View.

Associating your ViewModel with the top level View

Gluing Views to ViewModels occurs differently for top level objects and dependent objects.  For top level objects, this binding is accomplished by setting the top level View’s DataContext property to its ViewModel.

Josh Smith’s code does this programmatically in the app class:

Associating dependent ViewModels with their respective Views

We do not have to set the DataContext of any Views contained in the top level View. Once the top level DataContext is set, any elements on the container View should be aware of any public properties exposed by the top level ViewModel, since they will automatically inspect to visual tree in order to find a DataContext. 

Subsidiary Views are associated with properties on the top level ViewModel using DataTemplates and ContentControls.

In Josh Smith’s code, a  ContentControl is placed on the top level View in order to set an anchor for the association between the UserControl/View belonging to the top level View and the CollectionProperty/ViewModel belonging to the top level VM.  Here is a somewhat simplified version of what he does:

 

The HeaderedContentControl is combined with a TabControl are simply present to control how data is generally displayed.  The significant feature in this code is the binding on the Content property, which anchors the Workspaces property of our main ViewModel to this location.  In this case, the Workspaces property is an ObservableCollection of Workspace ViewModels:

Once the property is anchored, the appropriate View can be mapped to using a few WPF tricks:

 

In WPF DataTemplates normally have keys and a ContainerControl specifies the DataTemplate that will be applied to it based on those keys. By using the DataType property of a DataTemplate rather than setting a key, we invert this convention and let the DataTemplate determine what types of data it will be applied to.  In this case, we specify that this DataTemplate should be applied for any control with a Data Source of type WorkspaceViewModel.

You will also notice that instead of embedded Xaml inside the DataTemplate definition, we instruct the DataTemplate to apply a UserControl called AllCustomersView to WorkspaceViewModel.

There are some advantages to doing this.  First, Xaml embedded in the DataTemplate has no code-behind file whereas a UserControl does.  If you envision needing additional code to support your View, then this is a good route to go.  Second, UserControls are much easier to find in a Visual Studio solution than blocks of Xaml in a resource dictionary.  This makes UserControls a much better unit of work for organizing and maintaining code.  Finally (and this isn’t as trivial as it sounds) it gives us something we can call a “View” in the MVVM pattern.  WPF is so powerful, and allows us to do so many things in so many places, that it is useful to work with a View that can be treated as a fixed point around which we develop our applications. 

In Silverlight, sadly, DataTemplates can only be applied using named keys.  In Mr. Wildermuth’s code, the GameDetailsView UserControl is simply dropped into a Grid without the indirection of typed DataTemplates.  The Grid’s DataContext is then managed in code behind.

Another interesting feature of Mr. Wildermuth’s sample implementation is that he exposes raw Model objects.  While Mr. Smith’s implementation is careful to never expose Model objects, it could certainly be done without any obvious adverse affects.  For instance, the Workspaces property in Mr. Smith’s code exposes an ObservableCollection of WorkspaceViewModel objects.  It could just as well expose a collection of Customer objects, which is the type that WorkspaceViewModel encapsulates using containment.  This would affect our View code to the extent that we are using a keyless DataTemplate and must specify a type.  Had we chosen to specify a keyed template from the ContainerControl, however, then changes to the type of the collection would be transparent to our view.

The main advantage of wrapping our model objects in ViewModel objects is that we can coerce type conversions in the ViewModel rather than using TypeConverters in the binding in our XAML.  In general, a level of abstraction can always be useful.

The downside to using a ViewModel wrapper around our models is that in simple implementations we are simply duplicating each property of our Model object in the ViewModel.  This is a bit smelly.

How you implement MVVM will likely depend on your general coding tastes.  Some people like to encapsulate as much code as possible, while others prefer not to introduce abstractions unless they are actually required to accomplish a given task.  If you don’t use typed DataTemplates to apply your View to your ViewModel, then you have some flexibility in this regard.  The properties of your top level ViewModel can initially expose raw Model objects.  Should the need arise, you can later encapsulate your Model in a ViewModel without impacting the View.

Adding behavior through the Command infrastructure

Simply associating the View and the ViewModel in WPF takes care of data synchronization, assuming that your ViewModel implements INotifyPropertyChanged.  The other aspect of making the MVVM pattern work involves handling events on the View. 

In the MVP pattern, the Presenter typically handled events thrown by the View and routed them to the correct Presenter methods.

In MVVM binding is used on the View to associate events with actions on the ViewModel.

In Josh Smith’s code, this is accomplished by using DelegateCommands.  A DelegateCommand implements the ICommand interface and has an Execute method.  The Execute method, in turn, calls a delegate that has been associated with a specific DelegateCommand.  In Josh Smith’s code the DelegateCommand is called a RelayCommand.  There is an implementation of it provided in the Prism framework, as well as one in the MVVM Project Template included with WPF Futures.

To use DelegateCommands, you just need to first expose a property on your ViewModel of type ICommand.  Internal to the method a DelegateCommand instance is referenced that delegates to a private method on the ViewModel.  Here is a sample implementation from Josh Smith’s code:

 

The interesting part is how we bind to this property in our View.  In WPF controls typically have a default event that can be bound to a RoutedCommand by using the Command property.  The Command property, however, can also be bound to a property on the DataContext object that exposes an ICommand instance.

In our case, since the DataContext is already set to the ViewModel, we can simply take advantage of this to set the Command property of a Button to the SaveCommand property on our ViewModel:

There are a few shortcomings with this technique.  First, Silverlight 2 doesn’t support the Command property.  In Mr. Wildermuth’s example of MVVM, in fact, a button.clicked event is simply thrown and handled in code-behind;  the code-behind, in turn, calls a publically scoped method on the ViewModel.

The second shortcoming is that this only works if the default event handled by the Command is the one that you want.  If, in this case, we wanted to handle the right-clicked event, we would be out of luck.

There are several workarounds for this problem all involving creating attached properties to allow binding between control events and ViewModel commands.  John Grossman, who helped to promote the original MVVM pattern, has even dubbed it with its own pattern designation: the Attached Behavior Pattern, which works in WPF as well as Silverlight.

MVVM vs MVP

Technically, most of these binding techniques for data synchronization and behavior binding which are described as “MVVM” could be used in an MVP Supervising Controller implementation.  While traditionally one would hook up events between the View and the Presenter in the Presenter code, this seems a bit unnecessary since the binding works so well.  We aren’t changing responsibility between the Presenter and the View so much as we are simply finding a better way to facilitate this: instead of implementing an event specified in an IView interface, we are specifying the names of certain ICommand properties and allowing WPF to automagically hook it up for us.

As for data synchronization, while MVP Views typically know about model objects, there is no reason we couldn’t wrap model objects in containment objects just as, conversely, there is no reason we can’t expose raw model objects in MVVM rather than wrapped objects.

In the Prism sample implementations of the MVP pattern, moreover, the Presenter is often set as the View’s DataContext.  These similarities can make it difficult to distinguish between the two patterns in their wild habitat.  For instance, if you look at the source code for Scott Hanselman’s BabySmash application, you might be inclined, as I am, to identify it as an implementation of the MVVM pattern rather than the MVP pattern.

The key difference seems to be that in MVP the Presenter holds a reference to its correlate View, while in MVVM this is not the case.  In MVVM the ModelView/Presenter is unaware of the View that is being applied to it.  A typical Prism implementation of the MVP will look something like this:

In this case, dependency injection is used to pass a View object to the constructor of the Presenter.  The Presenter then sets its View property to this parameter value and ultimately returns it to the UI.

With the public View property on the Presenter, we are in the world of the MVP pattern.  Without it, we are probably in MVVM land.

A good way to differentiate patterns is to consider how and why they were developed in the first place.  The original concept behind the MVP pattern was to separate the View and the Presenter in such a way that the View had as little responsibility as possible. 

In the Passive View flavor of MVP, we weren’t even allowed to use the native binding provided in ASP.NET and WinForm development.  Instead, the Presenter was expected to populate each field on the View manually.

The Supervising Controller flavor of MVP, on the other hand, allowed us to provide a Model property on the View which the Presenter was responsible for populating.  The View itself, however, was able to bind its fields to this View.Model property itself.  This flavor of MVP gained popularity in large measure because it seemed silly not to use built in tools like binding for ideological reasons when it made development so much easier.

In WPF, we also have the ability to bind control events on the View to delegates on the ViewModel.  We could choose to wire these up manually if we wanted to, but again it seems strange to do this – and potentially introduce more errors – when WPF binding makes it unnecessary.

Set side by side, these three patterns resemble a child as it grows up.  In the Passive View pattern we are dealing with an infant and the Presenter is expected to feed and clean it.  I’ve tried letting infants feed themselves and it only leads to disaster.

In the Supervising Controller we allow the View to consume its own data, but we still take care of tying its shoes and any other details of hooking it up that are required.  It is still a toddler, after all.

In the MVVM, our baby has grown up.  Our View not only feeds itself but it also picks out its own food and ties its own shoes.  We don’t even have to keep an eye on it every hour of the day.  We can assume that it has a great degree of autonomy and can just come pull on our shirtsleeves if it runs into any problems.  It still needs to be aware of us, but we don’t need to be constantly aware of it.

For the most part this is where we want to be with regard to Views, but it comes at a cost.  When we place more code in our View we also make that code inaccessible for unit testing.  In WPF this doesn’t seem so bad because our code doesn’t show up in code-behind.  Instead it is marked up declaratively in Xaml.  And it’s mainly the code in code-behind that we care about testing, right? 

MVVM is probably for you if you are comfortable with either of the two following notions: 1) that Xaml isn’t really code, so it doesn’t need to be tested an 2) The whole point of declarative programming is that it behaves predictably, while the goal of unit testing is to capture unexpected behavior, so it doesn’t need to be tested.  If this causes you some discomfort, then MVVM is probably still for you if you feel that the convenience it provides outweighs any testability issues that might be raised – which is where I probably come down on the pattern.

Design Pattern Mutations

Like influenza, a design pattern can mutate over time.  This happens especially when it makes the species jump from one technology to another.

The Prism samples, in addition to the sample MVP implementations, also have an implementation of the MVVM that seems to combine aspects of both patterns.  In this implementation, the View keeps a reference to the PresentationModel, making it look like MVVM, while the PresentationModel also maintains a reference to the View much like a Supervising Controller.

The following code (modified slightly to simplify) can be found in the “Commanding” sample application for Prism:

Best of both worlds?