In-Depth
6 MVVM Tips: Leverage ViewModel and Unit Test Silverlight and WP7 Apps
The Microsoft Model-View-ViewModel pattern is an indispensable tool for developing applications for Silverlight, Windows Phone 7 and Windows Presentation Foundation. Benjamin Day helps you avoid architectural pitfalls and create unit-testable and maintainable applications.
- By Benjamin Day
- 04/01/2011
After working on a Silverlight 4 project for the last 18 months, I've learned a few things about layer loyalty, code organization, unit testing and maintainable code. Not surprisingly, I've formed some opinions on how to implement the Microsoft
Model-View-ViewModel (MVVM) pattern, and used the Repository and Adapter patterns to achieve better results. It sounds complicated but it doesn't have to be, especially with these six tips to help you avoid common architectural pitfalls and get the results you're after: separation of concerns, testability and easier maintenance as your application evolves.
First off, what is MVVM? It's a code organization and testability pattern commonly used in Silverlight, Windows Phone 7 and Windows Presentation Foundation (WPF) applications that helps you to bridge the gap between your UI code and your "business" tier or Domain Model code. The Views are your *.xaml files, the Models are your Domain Model objects and the ViewModels are logical representations of your Views minus the UI-specific stuff. Your ViewModel classes won't have any UI-specific types like TextBox or Label but will instead use types like string, int and DateTime. If you have a View named PersonDetail.xaml that allows the user to view and edit information about a person, you'll have a ViewModel class named PersonViewModel. If you've got a TextBox on your View that displays a Person's FirstName, you'll have a property on the ViewModel named FirstName that's a string. If you have a Save button on your View, you'll have a property on your ViewModel of type ICommand named SaveCommand. The Views and the ViewModels are connected together via databinding expressions on the UI controls.
Like its sister pattern, Model-View-Controller (MVC), MVVM helps you to unit test your application. It does this by minimizing the amount of code that lives in your codebehind (*.xaml.cs, *.xaml.vb) files. Why is minimizing your codebehind so crucial for unit testing? One of the key problems with unit testing is figuring out how to test a running instance of the UI. It's a challenge because unit test frameworks like NUnit and MSTest are geared toward testing ordinary classes. Sure, a XAML page is a class, but it comes along with a lot of other Windows-related stuff that's notoriously difficult to automate.
You might be thinking, don't Microsoft Test Manager (MTM) and Coded UI tests in Visual Studio 2010 fix this? Well, yes and no. These tools make it much easier to automate testing the UI of a running application, but it's a different kind of test. MTM and Coded UI tests are generally aimed at integration testing of a deployed application. There's a difference in mindset between "integration" testing and "unit" testing. Integration tests test the complete functionality of a deployed application while unit tests test small pieces of functionality in isolation. Integration tests are "macro" and unit tests are "micro." In a way, using MVVM and unit tests solves the UI testing problem by not testing the UI. The ViewModels are an abstraction representing the state and logic behind the UI, so you minimize the amount of stuff that's difficult to test and focus on what's easy to test -- the non-Windows ViewModel classes that you write in C# or Visual Basic .NET.
Tip 1: Separate the Model from the ViewModel, no matter what.
There's a tendency to want to lump your Model and your ViewModel into a single object. Let's take the case of a screen that edits information about a person: Id, FirstName, LastName, EmailAddress. If you don't have a heck of a lot of business logic or complex validation logic, having a PersonViewModel and a Person model class is going to feel a little like overkill or code duplication. These two classes are definitely going to be pretty similar. One of the great things about Silverlight/WPF and MVVM is being able to use data binding. You don't have to write 62 zillion assignment statements to get data from your ViewModel on to your View, and the codebehind for your View stays extremely clean. If you use two-way data binding, your ViewModel gets refreshed from your View as soon as the user clicks off of a field.
I learned the importance of strictly separating the Model from the ViewModel when I needed to implement a Cancel button.
Let's say you're editing an existing Person record and you're using two-way data binding. You change the first name, you change the last name, you change the e-mail address and then you realize that you're completely wrong and you want to undo your changes. At this point, the ViewModel is already updated because of the two-way data binding and has the same values that are displayed on the View.
If you "cheaped out" and combined the Model and ViewModel, you don't have anything to roll back to unless you reload the Person record from the database. But, if you have a separate ViewModel and Model, you simply don't migrate the changes to the Model.
Instead you refresh the ViewModel from the Model and your cancel functionality is complete.
This demonstrates a key point about layer loyalty. The Views and ViewModel are all about displaying stuff to the user in a particular UI implementation. The Model cares nothing about how the data is displayed and is more concerned with business rules and persistence logic.
The Views and ViewModels are for displaying and collecting data from the user, but when the actual Save happens, the data from the ViewModel gets copied to the Model and it's the Model that gets saved.
For the simple example of a Person editor, there's a 1-to-1 mapping between the View, the ViewModel and the Model. When your Views become more complex, this mapping changes. There's almost always a 1-to-1 mapping between the View and ViewModel, but when the Views (and therefore the ViewModels) get complex, the ViewModel might need to talk to two or more Models to populate and save the data on that View. This is the second case where "cheaping out" on the separation between View, ViewModel and Model can get you into trouble.
Tip 2: The classes from "Add Service Reference" are not your Models or your ViewModels.
If you're writing a Silverlight business application, you're probably using Windows Communication Foundation (WCF) to save and retrieve data. Silverlight can't directly connect to a database, so you really don't have any other options than to call up to some kind of Web service, which will connect to the database on your behalf. This means that you're probably going to be using Add Service Reference to generate proxy classes to help your Silverlight application talk to those services. If you're writing a WPF client to a service-oriented application, you're probably using Add Service Reference as well.
When these proxy classes are generated, they implement INotify-PropertyChanged, and that means that they can be used for two-way data binding. However, just because they can be used doesn't mean you should use them. It's another example of "layer loyalty." These classes are basically data-access classes, and they're loyal to that service and to the WCF implementation. How you save and load data isn't really related to a View -- it's related to the persistence implementation. Plus, if you think about it, WCF isn't really about objects anyway; it's about messages, so what you get back from WCF almost definitely isn't shaped the way you want.
Sure, it can be convenient to use these proxy objects as your ViewModels, but it isn't going to do you any favors when it comes to maintenance because all your layers are going to be tightly coupled. Your Views are tied directly to the operations and messages for the service. If the service contract changes, you have to change your View, and if your View changes you have to change your service (yuck).
Unless your application is really simple, these proxy objects aren't good candidates to be your Models, either. The proxy objects are simply data-transfer objects for talking to the service. The messages that go back and forth between your Silverlight client application, and the service application should be optimized for those operations.
They might have more or less data than you need for your model or, more importantly, aren't going to be the same shape as what you need. The messages might even be shaped a certain way in order to make them serialize more compactly.
Remember, your Models are Domain Model objects. They should be object-oriented (not message-oriented) and should represent how your client application thinks about the data it manages. If you use the service proxy objects as your Models, you're probably going to have some funky object designs. If you use the service proxy objects as your ViewModels, you not only skip having Models but also create a direct dependency between your XAML-based Views and your services. That's not a good recipe for code maintenance.
Tip 3: Separate your ViewModel and Model from your data-access logic with the Repository Pattern.
Your ViewModels represent the state of the UI and they should be experts in doing exactly that. They might have to make calls to get data saved and loaded, but they shouldn't be experts in how that's actually achieved. That's where the Repository pattern comes in.
The Repository is commonly thought of as a way to wrap reads and writes to a database on behalf of Domain Model objects -- but it doesn't have to be a database. The pattern is actually focused more on hiding the details of saving and retrieving Model data to/from a persistent store than on any particular kind of persistent store.
What this means for Silverlight (or any other client to a service-oriented application), is that you can and probably should encapsulate the logic for calling the services inside of a Repository pattern object. Additionally, once you encapsulate that logic inside of the Repository pattern, you can create an interface for that Repository and code against that in your application -- IPersonRepository instead of WcfPersonRepository.
Creating that Repository interface and coding against the interface type rather than the concrete type makes a big difference in how your unit tests work. Remember the goal when creating unit tests is to test small units of functionality. If you're testing how the PersonViewModel handles the data it gets back from calls to IPersonRepository, you don't really need to call the WcfPersonRepository. You can create a fake version of IPersonRepository that returns canned data. Now you're testing only the logic in PersonViewModel rather than the logic for PersonViewModel, the WcfPersonRepository and the WCF service.
This gives you a much more focused test. It makes your test and application code maintainable because your application logic is clearly separated from the data-access logic, which makes the application easier to debug.
Tip 4: Use the Adapter pattern between ViewModel and Model, and Model and Service Data Transfer Objects.
As stated previously, the ViewModel is going to collect data from your UI so that you can populate and eventually save your Models. With Silverlight, you're going to need to take the data from your Models and turn them into service proxy objects that you'll send through WCF. You also have to populate your ViewModels from Models and populate your Models from WCF service proxy objects. That's a fair number of gets and sets.
Rather than scattering that code throughout your classes in a bunch of different places, try using the Adapter pattern. The basic idea of the Adapter pattern is to take two different object structures and create a third object (the Adapter) to make them work together. In our case, the adapter is going to be responsible for the fairly tedious job of taking data from one type of object and putting it into another type of object -- ViewModel to/from Model and Model to/from WCF service project objects.
Having these gets and sets in your Adapter classes not only keeps your code organized but makes it easy to unit test the adaptation logic. I'm continually surprised by how error--prone this logic tends to be and, because of this, I think it's one of the most important places to unit test in an application.