Chapter 2. Introduction to MVVM

By Ryan Vice

In this chapter, we will introduce the Model View View Model pattern (MVVM) and help you better understand the current state of affairs of MVVM. This knowledge will lay a foundation that we will expand on throughout this book, to give you the tools and knowledge you need to take advantage of the many benefits of MVVM.

We will start with a brief history of the MVVM pattern, and then we will look at the structure of MVVM. Next, we will take a look at the features of WPF and Silverlight that make MVVM such an attractive option and follow this by diving into our first MVVM sample. Next, we will look at the benefits of using MVVM and discuss how we capitalized on those benefits in the MVVM sample that we built. We will follow this by looking at the challenges that can make MVVM difficult; addressing these challenges with various tools and techniques will be covered in the later chapters of this book and will make up a large majority of this book's...

History

MVVM is a pattern that emerged to address some of the limitations of MVC and MVP, and to combine some of their strengths. This pattern first hit the scene as a part of Small Talk's framework, under the name Application Model, in the '80s, and was later improved and given the updated name of Presentation Model.

Note

Application Model is also used to describe a hierarchical way of implementing MVVM, which will be covered in Chapter 6, Northwind—Hierarchical View Model and IoC

In the previous chapter, we reviewed a few shortcomings of MVC and how it dealt with view state and view logic, including the following:

• The view logic and view state were in the view and therefore difficult to test

• The view state and view logic were tightly coupled to the model and controller and were not reusable

These issues were addressed in the Passive View version of MVP by making the view a humble view and moving the view state and view logic into an external class.

Note

A humble view is a type of humble object...

Structure

With MVVM comes the concept of purity which refers to the amount of code in the code-behind. Here, we will be focusing on the pure approach—the style where no code is kept in the code-behind, and no references are kept between the view and view model.

Note

We will be covering varying degrees of purity, and the tradeoffs of each, in Chapter 4, Northwind—Services and Persistence Ignorance. However, if you are not interested in following the pure approach, you will still benefit from the material from this section, as it introduces the basic MVVM structure and sets up the design that will be used in our first example that will come later in this book.

Pure MVVM

Pure MVVM is structured as shown in the following diagram:

This structure is similar to MVP, except that there is no longer the IView interface for communicating from presenter to view. All communications between view and view model are now handled using WPF's and Silverlight's binding systems.

In MVVM, the model takes on the...

WPF and Silverlight enablers

.NET 3.0 introduced new toolkits for thick and thin client development, which included Silverlight for thin client development and Windows Presentation Foundation (WPF) for thick client development. At the heart of these new frameworks were features that allowed for much greater separation of concerns, including the following:

• A rich data binding system

• A commanding infrastructure

• Support for data templates

• A rich styling system

We will cover these features shortly, but for now it's important to know that these features in WPF and Silverlight made MVVM a practical reality as it provided the framework support needed for separating the view state and view logic from the view without requiring the overhead of writing property objects or using view interfaces.

There are many areas in the framework that could be improved to better support MVVM, and my guess would be that we will be seeing the road map for WPF and Silverlight incorporate more of the techniques and tools...

MVVM project billing sample

Now we will implement project billing using the MVVM pattern. Let's start by discussing the overall design.

MVVM design

The model, view, and view model are shown in the following screenshot, along with their relationships:

The view is now empty, and all of the explicit relationships that we've created between our classes are between the model and view model.

View Models

We will need two view models for this application. Each view model has its own area of responsibility in the view, as shown in the next screenshot.

Note

Using multiple nested view models in this way is what I call hierarchical view models, and it is a topic that will be explored in more detail in Chapter 6, Northwind — Hierarchical View Model and IoC.

ProjectsViewModel

The ProjectViewModel view model will contain the view state and view logic for ProjectsView. The following screenshot shows the mapping between Projects and ProjectsViewModel:

The property bindings and their responsibilities are shown as...

Benefits of MVVM

MVP had been the dominant presentational pattern for most UI development, with MVC still having a strong presence in web UIs before .NET 3.0 introduced some new technologies that made MVVM or Presentation Model an attractive option for WPF and Silverlight.

The benefits of MVVM include the following:

• Increased testability: Testability is improved as all view logic is now easily testable from unit tests.

• Less code: I've found that the amount of code required to manage the view has decreased quite a bit, as you no longer have to deal with boilerplate code behind code. This code involves a lot of casting and error checking in production quality code. Less code means fewer bugs, less code to maintain, and fewer unit tests to write.

• Increased decoupling: When using the pure approach, you no longer need to have the view and mediator (view model, presenter, or controller) be explicitly aware of each other. The view does have a reference to the view model via its DataContext property...

Issues and pain points of MVVM

There are some issues and pain points to implementing MVVM which include the following:

• Lack of direction from Microsoft: Microsoft hasn't given clear directions on this pattern yet, and the various non-Microsoft resources available on the topic can send mixed messages, leaving developers and architects confused.

• Need for boilerplate code, complicated techniques and/or frameworks: There are many areas in WPF and Silverlight where MVVM support can be improved. Things like property changed notifications and commands require lots of boilerplate code and potentially brittle designs that require using "magic strings". There are many frameworks and techniques out there that help address these issues. However, you may not want to or may not be allowed to use open source frameworks. Also, implementing the techniques that allow you to avoid using the frameworks can be complicated and require a good bit of boilerplate code to implement, as you will see later in this...

MVVM Light

There are many great MVVM frameworks out there, and we review many of them in Appendix A, but throughout this book we will be using the MVVM Light toolkit by Laurent Bugnion and GalaSoft. The toolkit is available for free on Code Plex (http://mvvmlight.codeplex) and offers many features, including:

• A lean framework that offers only what is needed for MVVM

• Project templates for both WPF and Silverlight, in both Visual Studio and Blend

• Blendability support is written into the templates

• Service locator pattern is written into the templates

• Item templates for Visual Studio and Blend

  • Create a new view model

  • Create a new view

  • Create a new view model locator, a class that holds and manages references to view models

• Code snippets to help increase productivity when implementing MVVM

  • mvvminpc adds a new bindable property to a view model

  • mvvmlocatorproperty adds a new view model to a view mode locator

  • mvvmpropa adds a new attached property to a dependency object (WPF only)

  • mvvmpropdp adds a new...

Summary

In this chapter, we got our feet wet with MVVM. We started things off with a quick review of the history of the pattern and its basic structure. We then covered the technologies in WPF and Silverlight that enable MVVM. Next, we built a version of the Project Billing sample application using MVVM and followed this by looking at the benefits of the pattern. We talked briefly about some of the issues and pain points with implementing MVVM and then finished off the chapter by looking at the MVVM Light toolkit that we will use later in this book.