Introduction to using MVVM mode to build WPF applications

Original article: Introduction to Model/View/ViewModel pattern for building WPF apps

Http://blogs.msdn.com/ B /johngossman/archive/2005/10/08/478683.aspx

By John Gossman (http://blogs.msdn.com/ B /johngossman)

Http://winter-cn.cnblogs.com (winter)

 

The MVVM mode is a variant of MVC. It is mainly tailored for modern UI development platforms where designers need to take more responsibilities for views than traditional developers. In general, designers are developers who focus more on graphics and aesthetics and do not write so many programs as traditional programmers do. Most of the designs are given in declarative languages like HTML or XAML, and most of the time they are generated using Dreamweaver, Flash, or WYSIWYG tools like Sparkle. In a word, the UI part of an application uses different tools and languages from the background data and business logic, and is completed by different people. The original design of MVC is aimed at a system built using the same environment and language for the whole program such as SmallTalk. Model/View/ViewModel is an improvement on MVC, it is used to adapt to the well-known Web environment and the current avron Development (annotation: avron is the WPF codename. This blog was released earlier and the name of WPF has not been determined yet ).

 

Model/View/ViewModel also depends on one thing: an overall data binding mechanism. Later.

As defined in MVC, Model is data or business logic, completely unrelated to the UI. It stores the status and handles problems in the field. The Model can be written in the code or in a relational table or XML.

The View in Model, View, or ViewModel indicates visible elements, buttons, forms, images, or more complex controls in the GUI. It encodes the shortcut keys, in addition, the control itself manages the interaction with the input device-this is the responsibility of the Controller in MVC (the issue that occurs on the Controller in the modern GUI environment is a long topic ...... I tend to think that it is only hidden in the background, and it still exists, but we don't need to think about so many things as we did in 1979 ). A View is almost always defined in a declarative manner, and is usually generated by a tool. Because of these tools and the natural characteristics of clear language, some View States encoded by MVC in its View class are not easily expressed. For example, the UI may have multiple interactive modes, such as "display status" and "Edit status", which change the behavior or visible appearance of the control, however, these patterns are not always expressed in XAML (although triggers are a good starting point ). We will solve this problem later.

At this time, data binding is required. In a simple example, the View is directly bound to the Model. Some parts of the Model are simply displayed to the view through one-way binding. Other parts of the Model can be edited using controls that bind data in two directions. For example, a Boolean value in a Model can be bound to a CheckBox or a TextBox string field.

However, in practice, only a few program UIS can directly bind data to the Model, especially when the Model is an existing class or data format, when application developers cannot control it. The UI may want to perform complex operations that must be completed in the code, which is unreasonable in our strict View, in addition, it seems that the Model is too specific to specific problems (or you may not be able to get an existing Model at all ). In the end, we need to put the view State in one place, such as selection and mode.

ViewModel is used to process these tasks. The term "View Model" can be seen as an abstract View, but it also provides a specific form of Model dedicated to binding data to the View. In the latter role, ViewModel includes a data converter that converts the Model type to the View type, and contains the commands that View can use to interact with the Model.

I will expand these ideas and focus on how to bind views to ViewModel commands in the following articles. However, the quickest way to clarify this mode is to provide some instances:

The preceding figure shows three editing panels of the Sparkle UI. Each is developed in Model/View/ViewModel mode. The simplest is the top Library panel. Model is a list of an Assembly (each is an instance of System. Reflection. Assembly), and each Assembly corresponds to a list of controls. View is our panel control and a series of Style and DataTemplate. they display the Assembly list to a ComboBox and display the control list in a ListBox. We bind the title data of ComboBox to the name of the Assembly object, and let the list items in ListBox extract the text they need from the name of the Control. ViewModel has a command like the currently selected Assembly and exposes it to insert a control to the scenario. Selection is the most commonly used component in ViewModel. You may wonder why selection is not placed in View. The reason for this is that many controls in the view need to collaborate based on single choice. Compared with all the different controls in the view, ViewModel can easily be bound to a single-choice representation. On the Library panel, the selected Assembly determines what is selected in ComboBox and what data is displayed in ListBox. In addition, the designer is free to switch to the ListBox display assembly and use ComboBox to display the control list, without having to copy the same selection logic from the original view.

The Appearance panel uses the selected shape or control in the Sparkle editing area as its Model. There is a ListBox in the View, which is used to display interesting attributes in the current selection (at least some Pen and Brush attributes), and buttons used to determine whether the Brush or Pen is simple or gradient, and the chromatography used to edit the color components. The ViewModel includes the selected attributes, the gradient transition point selected when editing the gradient, and the data converter that maps the color to the text value and the chromatography, and commands used to replace the Pen and Brush being edited. In this case, the Model is provided by aveon, And the View can be easily changed to something completely different, while the ViewModel provides a completely different representation of reusable components in the UI.

The last example is our Project panel. Here the Model is a MSBuild Project ...... Once again, the Model class exists in advance. View is a tree-type control that provides a scrolling area and a content menu. ViewModel is adapted to concepts in MSBuild that are not specifically designed for aveon (and can work perfectly from the command line), so that we can bind data to them. ViewModel still contains selection information and commands.

Once you have an understanding of Model, View, and ViewModel, any UI problem can be expressed in terms of it. In fact, the entire Sparkle UI is defined in this mode. The "selected shape or control in the editing area" is the Model of the Appearance panel, which itself is a concept in the ViewModel of our Scene editor. The layout of the Sparkle internal Panel. The registered panel list is its Model. The View is based on the Grid with splitter to locate the View and the ViewModel is used to determine which panels are currently visible, and the logical container in which they are located (editing area, left, right, bottom edge ).