Two other features of WPF that make this pattern so usable are data templates and the resource
system. Data templates apply Views to ViewModel objects shown in the user interface. You can
declare templates in XAML and let the resource system automatically locate and apply those
templates for you at run time. You can learn more about binding and data templates in my July
2008 article, " Data and WPF: Customize Data Display with Data Binding and WPF
﴾https://msdn.microsoft.com/magazine/cc700358﴿."
If it were not for the support for commands in WPF, the MVVM pattern would be much less
powerful. In this article, I will show you how a ViewModel can expose commands to a View, thus
allowing the view to consume its functionality. If you aren't familiar with commanding, I recommend
that you read Brian Noyes's comprehensive article, " Advanced WPF: Understanding
Routed Events and Commands in WPF
﴾https://msdn.microsoft.com/magazine/cc785480﴿," from the September 2008 issue.
In addition to the WPF ﴾and Silverlight 2﴿ features that make MVVM a natural way to structure an
application, the pattern is also popular because ViewModel classes are easy to unit test. When an
application's interaction logic lives in a set of ViewModel classes, you can easily write code that tests
it. In a sense, Views and unit tests are just two different types of ViewModel consumers. Having a
suite of tests for an application's ViewModels provides free and fast regression testing, which helps
reduce the cost of maintaining an application over time.
In addition to promoting the creation of automated regression tests, the testability of ViewModel
classes can assist in properly designing user interfaces that are easy to skin. When you are designing
an application, you can often decide whether something should be in the view or the ViewModel by
imagining that you want to write a unit test to consume the ViewModel. If you can write unit tests
for the ViewModel without creating any UI objects, you can also completely skin the ViewModel
because it has no dependencies on specific visual elements.
Lastly, for developers who work with visual designers, using MVVM makes it much easier to create a
smooth designer/developer workflow. Since a view is just an arbitrary consumer of a ViewModel, it
is easy to just rip one view out and drop in a new view to render a ViewModel. This simple step
allows for rapid prototyping and evaluation of user interfaces made by the designers.
The development team can focus on creating robust ViewModel classes, and the design team can
focus on making user‐friendly Views. Connecting the output of both teams can involve little more
than ensuring that the correct bindings exist in a view's XAML file.
The Demo Application
At this point, I have reviewed MVVM's history and theory of operation. I also examined why it is so
popular amongst WPF developers. Now it is time to roll up your sleeves and see the pattern in
action. The demo application that accompanies this article uses MVVM in a variety of ways. It
provides a fertile source of examples to help put the concepts into a meaningful context. I created
the demo application in Visual Studio 2008 SP1, against the Microsoft .NET Framework 3.5 SP1. The
unit tests run in the Visual Studio unit testing system.
The application can contain any number of "workspaces," each of which the user can open by
clicking on a command link in the navigation area on the left. All workspaces live in a TabControl on
the main content area. The user can close a workspace by clicking the Close button on that
workspace's tab item. The application has two available workspaces: "All Customers" and "New
Customer." After running the application and opening some workspaces, the UI looks something
like Figure 1.
Figure 1 Workspaces
Only one instance of the "All Customers" workspace can be open at a time, but any number of "New
Customer" workspaces can be open at once. When the user decides to create a new customer, she
must fill in the data entry form in Figure 2.