The types in this namespace help to implement the MVVM pattern. For a nice introduction to MVVM please refer to Ivo Manolov's Blog.

Note
Please ignore the section discussing the ICommand interface and its implementation. We will see below how ICommand is no longer necessary with XAML frameworks that offer triggers or behaviors.

To summarize, the important facts of MVVM are the following:

• At compile time, there is a unidirectional dependency between the different entities: The View references the ViewModel, which in turn references the Model. However, the ViewModel does not know anything about the View and the Model does not know anything about the View or the ViewModel.

• The main responsibility of the ViewModel is to provide the data in the format needed by the View, offer methods for the actions that can be performed on the View and provide events that the View needs to subscribe to.

• The ViewModel is fully GUI-technology-agnostic and can be exercised by automated tests.

• The View defines how the data of the ViewModel is presented to the user. It is often implemented solely in XAML. In the cases where C# code is necessary, the code only concerns itself with the presentation of the data but not the business logic.

• The Model is implemented without consideration for how the GUI will look like. It simply provides all necessary data, offers methods to modify the data and enforces the business logic. The data is provided in the format that is most convenient and efficient for the Model.

A ViewModel is particularly easy to consume from a XAML-based GUI (WPF, Silverlight, Windows Store App, etc.):

• Databinding: Normal properties as well as ObservableCollectionT properties can be bound to controls directly in XAML (no code behind is necessary). Changes in the GUI are automatically pushed to the bound properties and changes to the properties automatically lead to updates of the GUI.

• Control Behavior: ControlIsEnabled and similar GUI behavior properties can be bound to properties of the ViewModel directly in XAML.

• Triggers and Behaviors: Events on GUI controls can be bound to ViewModel methods directly in XAML, such that a method is called whenever the associated event is raised (see CallMethodAction).

Note

For simple applications, it is often unclear at first where to best draw the line between the Model and the ViewModel. If one follows the MVVM pattern to the letter and implements all the business logic in the Model, the ViewModel often degenerates into a class that does little else than forward function calls between the Model and the View. In such cases I think it is perfectly acceptable to implement much or even all business logic in the ViewModel. Note that the most important aspect of MVVM is the separation between View and ViewModel. Whether and where to separate the Model from the ViewModel is of lower importance and should be decided based on the use cases. For example, the Model in the Glow Analyzer Proxy application is the Settings class, which is responsible for the storage of the application settings. All other business logic is implemented in the MainWindowViewModel.

This topic contains the following subtopics:

• Data Synchronization

• Example