Alternative View / ViewModel Configurations
Throughout this chapter, we've demonstrated the scenario where we have a one-to-one relationship between the views and the ViewModels, with each ViewModel representing its corresponding view as a whole. This is an ideal scenario for learning the pattern (and reasonably common in practice), but it isn't a fixed requirement. Let's take a look at some additional configurations you may come across or want to use yourself.
One ViewModel Serving Multiple Views
In some scenarios, you may have one ViewModel that serves multiple views, such as a wizard. In this case, the ViewModel-first approach might be best.
One View Interacting with Multiple ViewModels
Alternatively, a single view may interact with multiple ViewModels. Instead of having the ViewModel exposing model objects directly to the view, some developers choose to wrap their model objects in ViewModels, abstracting the model from the view. Instead of the view binding directly to the data (i.e., the models), it will bind to a ViewModel instead.
For example, a view may populate a list box with a collection of ProductViewModel objects, with each wrapping a Product model object. These ViewModels could essentially be considered a “view of the model.” Additional properties, calculations, logic, and so on, could be added to these ViewModel objects, serving the needs of the view while saving the model from being polluted with view-related requirements.
Note Another potential benefit of this practice is that it can save needing to implement value converters in your bindings to convert the property values of the model to suit the needs of the view. Instead, these conversions can be performed within the ViewModel and exposed as properties that the view can directly bind to and consume. For example, rather than implementing a value converter to convert a Boolean value exposed by a property on the ViewModel to a Visibility value, you could expose the Visibility value directly from the ViewModel. That said, doing this tends to make your ViewModel a little too coupled to the needs of the view, which some developers consider to be a bad practice. Therefore, if you choose to do this, do so sparingly.
The big issue with the practice of wrapping all your model objects in ViewModels is the amount of overhead and additional code required to wrap each of the model objects in a ViewModel—often resulting in properties on the ViewModel that purely exist to relay property values from the model objects. Most of the time, the outcome of this practice is simply an unnecessary duplication of code. Therefore, whether you undertake this practice will generally be on a case-by-case basis.
Note The XAML Power Toys add-in (discussed in Chapter 7) has a Create ViewModel For Class option that you can use to take a lot of the manual work out of the task of wrapping model objects in ViewModels.