Design Patterns-issues and solutions for using Model-view-viewmodel

Windows presentation Foundation (WPF) and Silverlight provide a rich API for building modern applications, but it can be difficult to understand and consistently apply all the WPF features to build well-designed, maintainable applications. Where do I start? What kind of method is the correct application design method?

The Model-view-viewmodel (MVVM) design pattern describes common methods for building WPF or Silverlight applications. It is also a powerful tool for building applications and a common language for discussing application design with developers. Although MVVM is really useful, it has not been developed for long and the user has not yet formed a correct understanding.

When is the MVVM design pattern applicable and when is it unnecessary? How should the structure of the application be designed? ViewModel layer How much code to write and maintain, what alternative way to reduce the amount of ViewModel layer of code? How to properly handle the related properties in Model? How do i show the collections in Model in View? Where should I instantiate the ViewModel object and hook it up to the Model object?

In this article, I'll explain how ViewModel works and discuss the pros and cons of implementing ViewModel in your code. I'll also show you some concrete examples of how to use ViewModel as a document manager to display the Model object in the view layer.

Model, ViewModel and View

So far, every WPF and Silverlight application I've designed has the same high-level component design. Model is the core of the application and requires a lot of effort to design in accordance with object-oriented analysis and Design (OOAD) best practices.

For me, Model is the core of the application, representing the largest and most important business asset, because it records all the complex business entities, their relationships, and their capabilities.

Model above is ViewModel. The two main goals of ViewModel are: Make model easy to be used by Wpf/xaml view, separate model from view and encapsulate model. These goals are, of course, very good, but for some practical reasons, these goals are sometimes not achieved.

The ViewModel you build knows how users will interact with the application at the top level. However, ViewModel is ignorant of View, which is an important part of the MVVM design pattern. This allows interaction designers and graphic designers to create graceful, effective uis on a ViewModel basis, while working closely with developers to design appropriate ViewModel to support their work. In addition, the separation of View and ViewModel also makes ViewModel more useful for unit testing and reuse.

To enforce a strict separation between the Model, View, and ViewModel layers, I like to build each layer as a separate Visual Studio project. With reusable utilities, major executable assemblies, and any unit test project you have a lot of these, right? Combined, this results in a large number of projects and assemblies, as shown in Figure 1.

Figure 1 part of the MVVM application

Because this strict separation method produces a large number of projects, it is clearly best suited for large projects. For small applications with only one or two developers, the benefits of this strict separation may not offset the inconvenience of creating, configuring, and maintaining multiple projects, so just separating your code into different namespaces in the same project may be better than adequate isolation.

Writing and maintaining ViewModel is not easy and should not be treated lightly. However, the answers to some of the most basic questions (when MVVM design patterns are applicable and when they are unnecessary) are often included in your domain model.

In large projects, the domain model can be very complex, and hundreds of classes need to be carefully designed so that they can be seamlessly combined in any type of application, including Web services, WPF, or asp.net applications. Model may consist of several compatible assemblies, even in very large organizations, where domain models are sometimes built and maintained by a dedicated development team.

If you have a complex large domain model, it is almost always beneficial to introduce the ViewModel layer.

On the other hand, the domain model is sometimes very simple and may simply be a thin layer covering the database. Classes can be generated automatically and typically implement INotifyPropertyChanged. The UI is usually a series of lists or tables that you can edit to allow the user to manipulate the underlying data. The Microsoft toolset has always been extremely adept at building such applications easily and quickly.

If your model or application is of this type, ViewModel is likely to incur unacceptably high overhead and does not have sufficient benefits for your application design.

Even in these cases, however, ViewModel still has its value. For example, ViewModel is ideal for implementing the Undo feature. Alternatively, you can choose to provide Model directly to View in some part of the application (for example, document management, which I will discuss later) using MVVM.

Why do you use ViewModel?

Even if ViewModel looks right for your application, there are still questions to answer before you start coding. One of the most important issues is how to reduce the number of agent properties.

MVVM design mode separates View from model, which is an important and valuable aspect of the pattern. Therefore, if the Model class has 10 properties that need to be displayed in View, then ViewModel will eventually have 10 equivalent properties, which are simply proxies for calls to the underlying model instance. These proxy properties typically raise property change events when they are set, informing View that the property has changed.

Not every model property has ViewModel agent properties, but each model property that needs to be shown in View usually has an agent property. The agent properties are usually shown below:

public　string　Description　{
　 get　{
　　 return　this.UnderlyingModelInstance.Description;
　 }
　 set　{
　　 this.UnderlyingModelInstance.Description　=　value;
　　 this.RaisePropertyChangedEvent("Description");
　 }
}