Tag Archives: Party Tricks

MVVM: UI design patterns in the wild

The Ascent of Man

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:

    MainWindow window = new MainWindow();

    var viewModel = new MainWindowViewModel();

    window.DataContext = viewModel;

    window.Show();

 

Shawn Wildermuth elegantly accomplishes this in XAML using Binding to set the DataContext of the View to a ViewModel loaded as an object resource:

 

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:

        public ObservableCollection<WorkspaceViewModel> Workspaces

        {

            get

            {

                if (_workspaces == null)

                {

                    _workspaces = new ObservableCollection<WorkspaceViewModel>();

                    _workspaces.CollectionChanged += this.OnWorkspacesChanged;

                }

                return _workspaces;

            }

        }

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:

    public ICommand SaveCommand

    {

        get

        {

            if (_saveCommand == null)

            {

                _saveCommand = new RelayCommand(

                    param => this.Save(),

                    param => this.CanSave

                    );

            }

            return _saveCommand;

        }

    }

 

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:

    EmployeesPresenter presenter = this.container.Resolve<EmployeesPresenter>();

 

    IRegion mainRegion = this.regionManager.Regions[RegionNames.MainRegion];

    mainRegion.Add((UIElement)presenter.View);

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:

    public OrdersEditorView View { get; private set; }

 

    public OrdersEditorPresentationModel(OrdersEditorView view)

    {

        View = view;

        view.Model = this;

    }

Best of both worlds?

Alternatives to returning Void: Continued

“If you look long enough into the void the void begins to look back through you." – Nietzsche

Returning types rather than void on methods that do not necessarily require a return value, as occurs in the implementation of the Append methods on the StringBuilder, allows us to do some interesting method chaining in our code.

Bill Wagner suggests doing something similar with collections in More Effective C# .  My examples are a bit more contrived, however.

Suppose – for the sake of the premise if for nothing else – that we have a business requirement to take a decimal collection of prices and then add 6 percent to each collection member.  We could write the following custom collection to do this:

    public class Prices: IEnumerable<decimal>
    {
        private List<decimal> _mySequence;
        public Prices()
        {
            _mySequence = new List<decimal>();
        }
        public Prices Add(decimal d)
        {
            _mySequence.Add(d);
            return this;
        }
        public IEnumerator<decimal> GetEnumerator()
        {
            foreach (decimal d in _mySequence)
                yield return d;
        }
        IEnumerator IEnumerable.GetEnumerator()
        {
            foreach (decimal d in _mySequence)
                yield return d;
        }
        public Prices AddSixPercentAndWrite()
        {
            foreach(decimal d in _mySequence)
                Console.WriteLine(string.Format("{0:C}",d * 1.06m));
            return this;
        }
    }

Which we would then call thus:

        var prices = new Prices();
        for(decimal d = 0; d< 20m;d++)
        {
            prices.Add(d);
        }
        prices.AddSixPercentAndWrite();
 

The business is initially happy with this, but then comes back a week later to say that the six percent tax is nine percent in a different store. Additionally, while sometimes the business wants to see the final price, they also sometimes want to see the original price alongside of it. 

Besides our original output, we now also need to be able to push a list that looks something like this:

$0.00 $0.00

$1.00 $1.06

$2.00 $2.12

$3.00 $3.18

$4.00 $4.24

$5.00 $5.30

$6.00 $6.36

$7.00 $7.42

$8.00 $8.48

$9.00 $9.54

$10.00 $10.60

$11.00 $11.66

$12.00 $12.72

. . .

Seeing where this is headed, we realize that to handle all foreseen and unforeseen scenarios, we should come up with a way to chain up our methods in order to make the code more flexible.

We could restructure the AddSixPercent method to take a parameter; we could then break out the Write method so we can call it multiple times if needed.  We could also change the signatures on our methods to return our Prices collection instead of void, allowing us to chain the methods together.

There’s a hitch, however.  While returning Prices would allow us to do some chaining, we still wouldn’t get the right results since each method would iterate through the whole collection before returning.  Consequently we would end up printing out all the items in the first column before getting around to printing the items in the second column (the calculated cost with tax), which isn’t what we want at all.

. . .

$12.00

$13.00

$14.00

$15.00

$16.00

$17.00

$18.00

$19.00

$0.00

$1.06

$2.12

$3.18

$4.24

$5.30

$6.36

$7.42

$8.48

$9.54

$10.60

$11.66

$12.72

. . .

By using iterators, on the other hand, every method in our chain would act on a particular iteration rather than on the whole sequence.  Besides getting the output that we want, this would also happily give us much more efficient code since we only have to iterate through our collection once rather than once per chained method call.

If we are to use iterators, however, we can’t return the Prices type.  Instead we have to return an IEnumerable type.  Leaving the rest of our Prices custom collection class alone, here’s what that new code would look like:

public static IEnumerable<decimal> AddXPercent(IEnumerable<decimal> sequence
    , short percent)
{
    foreach (decimal d in sequence)
        yield return d + (d * percent * .01m);
}
 
public static IEnumerable<decimal> WriteToConsole(IEnumerable<decimal> sequence)
{
    foreach (decimal d in sequence)
    {
        Console.Write(string.Format("{0:C} ", d));
        yield return d;
    }
}

Our calling code, in turn, would look like this:

    foreach (decimal d in Prices.WriteToConsole(
        Prices.AddXPercent(
        Prices.WriteToConsole(
        prices), 6)
            )
        )
        Console.WriteLine();
 

We’ve managed to achieve chaining, but not so elegantly, all things considered.  First, we have to include the name of our Type in order to chain our methods together.  Second, the chaining is done with nested methods instead of the clean With-like syntax I was extolling in the previous post.  Finally, the sequence of activity isn’t particularly clear.  Because we are chaining our methods by using nesting, the innermost nested method occurs first, while the first shall be processed last.

Fortunately extension methods allow us to alter the way our methods are called.  In order to get the sort of syntax we want, we just need to pull our iterator methods into an extension methods class like so:

    public static class PricesExtension
   {
        public static IEnumerable<decimal> AddXPercent(
            this IEnumerable<decimal> sequence
            , short percent
            ) 
        {
            foreach (decimal d in sequence)
                yield return d + (d * percent * .01m);
        }
 
        public static IEnumerable<decimal> WriteToConsole(
            this IEnumerable<decimal> sequence
            )
        {
            foreach (decimal d in sequence)
            {
                Console.Write(string.Format("{0:C} ", d));
                yield return d;
            }
        }
    }

Giving us the results we were looking for:

$0.00 $0.00

$1.00 $1.06

$2.00 $2.12

$3.00 $3.18

$4.00 $4.24

$5.00 $5.30

$6.00 $6.36

$7.00 $7.42

$8.00 $8.48

$9.00 $9.54

$10.00 $10.60

$11.00 $11.66

$12.00 $12.72

. . .

 

We can now call our code like this:

    foreach(var d in prices
            .WriteToConsole()
            .AddXPercent(6)
            .WriteToConsole()
            )
            Console.WriteLine();

This alternative to returning void involves three tricks:

1) Returning an IEnumerable type instead of void.

2) Taking an IEnumerable type as a parameter.

3) Using these signatures in extension methods rather than the custom collection class itself.

If the syntax looks familiar, this is because this is also how LINQ to Objects is implemented.  For that very reason, we could have accomplished similar results by using LINQ:

    foreach(var d in prices
        .Select(d => { Console.Write(string.Format("{0:C} ", d)); return d; })
        .Select(d => d + (d * 6 * .01m))
        .Select(d => { Console.Write(string.Format("{0:C} ", d)); return d; })
        )
    {
        Console.WriteLine();
    }

It’s funky code, no doubt, but I also find it highly compelling.  I know that as I loop through my prices, I am writing out the original price, I add 6 percent to it in the following line, then I write out that result in the final line.  Inside the foreach block, I then perform any follow-up operations: in this case, writing a new line.

Alternatives to returning Void

I was playing with the Unity Framework recently when I came across the following C# code sample on msdn:

    IUnityContainer uContainer = new UnityContainer()
        .RegisterType<IMyInterface, FirstObject>()
        .RegisterType<MyBaseClass, SecondObject>();
    MyObject myInstance = uContainer.Resolve<MyObject>();

This looked so much like the VB With syntax that I uncharitably assumed that the authors at MSDN had somehow confused C# and VB.  After all, they had written this the standard C# syntax elsewhere:

    // Create container and register types
    IUnityContainer myContainer = new UnityContainer();
    myContainer.RegisterType<IMyService, DataService>("Data");
    myContainer.RegisterType<IMyService, LoggingService>("Logging");
 
    // Retrieve an instance of each type
    IMyService myDataService = myContainer.Resolve<IMyService>("Data");
    IMyService myLoggingService = myContainer.Resolve<IMyService>("Logging");

C# developers with more than 8 or so years of experience can generally be broken down into two types who are mutually suspicious of one another: those who came up through the VB6 programming ranks and those who came up through C++ or Java.  I did the former, and for the most part have never looked back.  I don’t even get involved in disputes between C# lovers and VB lovers.  They’re both nice language.  I just happen to use the former for most things.

The one thing I do miss from VB, however, is the With command.  It always seemed an elegant piece of syntactic sugar and easier to read when you find code that manipulates the same object repeatedly.  My “you can’t do that on television” moment over the msdn sample code came out of that longing for something I thought I’d simply had to leave behind.

It took me a while to realize that the sample code was taking advantage of a trick that has always been available to C# developers but just not extensively used. (I even had to show it to several colleagues just to make sure I wasn’t just being slow – everyone’s first thought, blessedly, was that it was somehow a VB-to-C# translation mistake.) The trick is that the RegisterType method is returning an IUnityContainer object.  Because a C# statement, unlike a VB statement, can be spread out over multiple lines in the editor until a semicolon delimiter is encountered, the code can be made to take on this VB-ish cast.  In fact, the Append method of the StringBuilder type similarly returns its own container type, making the following code blocks equivalent:

    StringBuilder sb = new StringBuilder();
 
    // this code ...
    sb.AppendLine("one");
    sb.AppendLine("two");
    sb.AppendLine("three");
 
    // is equivalent to this ...
    sb.AppendLine("one").AppendLine("two").AppendLine("three");
 
    // is equivalent to this ...
    sb.AppendLine("one")
      .AppendLine("two")
      .AppendLine("three");

This trick won’t work for properties, of course, but it is still pretty fun, and I’m kicking myself for never having come across it earlier.