MVVM is an architectural pattern that facilitates the clear separation of the GUI with the logic. It provides a clean separation between application’s user interface, its presentation logic, and its business logic and data by separating each into separate classes. The MVVM pattern is a close variant of the Presentation Model pattern, optimized to leverage some of the core capabilities of WPF and Silverlight, such as data binding, data templates, commands, and behaviors.
The separation of application logic and UI helps to address numerous development and design issues and can make the application much easier to test, maintain, and evolve. It can also greatly improve code re-use opportunities and allows developers and UI designers to more easily collaborate when developing their respective parts of the application.
Some of the benefits achieved by using MVVM are explained in detail below:
- Concurrent Development: One of the biggest advantage is that during the development process, developers and designers can work more independently and concurrently on their components. The designers can concentrate on the view, and if they are using Expression Blend, they can easily generate sample data to work with, while the developers can work on the view model and model components.
- Testability: The developers can create unit tests for the view model and the model without using the view.
- Easy Redesign of the UI: It is easy to redesign the UI of the application without touching the code because the view is implemented entirely in XAML. A new version of the view can easily be worked upon and plugged into the existing view model.
In the MVVM pattern, the UI of the application and the underlying presentation and business logic is separated into three separate classes: the view, which encapsulates the UI and UI logic; the view model, which encapsulates presentation logic and state; and the model, which encapsulates the application’s business logic and data. The view interacts with the view model through data binding, commands, and change notification events. The view model queries, observes, and coordinates updates to the model, converting, validating, and aggregating data as necessary for display in the view.
The interaction between the classes is explained in the diagram below:
Class Interactions Diagram
Characteristics of the View Class
- The view in the MVVM pattern defines the structure and appearance of what one sees on the screen.
- As a thumb rule, one should not put any logic code that needs to be tested by unit test in the View.
- The view is a visual element. The view defines the controls contained in the view and their visual layout and styling.
- The view can customize the data binding behavior between the view and the view model by using the Value converters to format the data or by using the validation rules to provide additional input data validation to the user.
- The view defines and handles UI visual behavior, such as animations or transitions that may be triggered from a state change in the view model or via the user’s interaction with the UI.
Characteristics of View Model:
- The view model is a non-visual class and does not derive from any WPF or Silverlight base class.
- It encapsulates the presentation logic and is testable independently of the view and the model.
- The view model does not reference the view. It implements properties and commands to which the view can data bind. It notifies the view of any state changes via change notification events via the INotifyPropertyChanged and INotifyCollectionChanged interfaces.
- The view model acts as coordinator between the view and the model. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model.
- It may also implement data validation via the IDataErrorInfo or INotifyDataErrorInfo interfaces.
- The view model may define logical states that the view can represent visually to the user.
- Typically, there is a one-to many-relationship between the view model and the model classes.
- In most cases, the view model will define commands or actions that can be represented in the UI and that the user can invoke.
Characteristics of the Model Class
- The model in the MVVM pattern encapsulates business logic and data. Business logic is defined as any application logic that is concerned with the retrieval and management of application data and for making sure that any business rules that ensure data consistency and validity are imposed.
- As a thumb rule models should not contain any use case–specific application logic.
- Mostly the model represents the client-side domain model for the application. It can define data structures based on the application’s data model and any supporting business and validation logic.
- The model classes do not directly reference the view or view model classes and have no dependency on how they are implemented.
- The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.