MVVM mode in WPF

MVVM mode in WPF
Zhou yinhui

The topic "Design Pattern" seems to be easily written by the brothers in the garden, from simple factory to MVC, MVP. MVVM seems to have a little talk about it. Let's talk about it briefly today. it is worth noting that: Here we only talk about some of our own understandings of the things invented by others, which may be biased and expected to be understood. in addition, after searching, "clingingboy" and "Gao Yang" in the garden also talked about this model. You may wish to refer to it.
Before reading the following content, we recommend that you have some knowledge of this content: WPF, MVC, MVP, MVVM. For more information about the MVVM syntax level, see here: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

1. Prerequisites
It can be said that MVVM is a model designed for WPF, or MVVM is just a variant of MVC. However, in practice, if you or your team are not used to Binding, it makes little sense to study MVVM.
In addition, I personally think that using Command and creating a reasonable and simplified way to use Command is equally important as using Binding.

2. Birth
To solve problems in the real world, we need to abstract things in the real world, and then get the Domain Object, no matter the anemia or rich blood, we can all simply attribute them to "the model abstracted from the real world", that is, our model, that is, the "M" in the M-V-VM ".
However, it cannot interact with our users. Therefore, we need to create an interface (View, View) for it. This View can interact with user input devices, which is great, but the question is, how can we associate a View with our model? Binding can be used. For example, the text in a text box in the view is associated with the "user name" in the Model, you can access and modify the "user name" of the Model by using the text box.
This is extremely simple, but in actual programming, we found that the attributes (and methods) in the Model are often less easily associated with the interface controls in the View, for example, "Type mismatch ": the type required by the interface control does not match the type raised by the attribute in the model. "Additional operations required": Data in the model must be processed to be transmitted to the view, and vice versa. at this point, we realized that the View seems to require a "Helper" class to handle some extra work.
The Code contained in this helper can be put in many places except the Model (we do not consider the debate about anemia and rich blood), such as in the View, I remember that I did this when I first learned how to develop a form program. I put the vast majority of the processing logic in the so-called CodeBehind. later, in order to separate the View and Model, the implemented view can be replaced (for example, you can say that the software you carefully designed runs on the Form program, Web or even Mobile), and MVC is available. with MVC, it seems that the debate and variant models such as M-V-XXX, such as MVP and MVVM, and even MVP also have two ways of Supervising Controller and Presentation Model. but there are two main problems: first, the relationship between model and view is completely isolated? Unidirectional or bidirectional? Second, what functions does this "XXX" need to complete and simple process scheduling? Complex rule processing? Okay, there is no relationship between these arguments. Whether or not to adopt a certain mode depends on your development environment (such as language features and framework features) and your business features and the main changes you face.
However, unlike MVC and MVP, MVVM is introduced not only for technical reasons, but also for the following reasons: the development method of the software team has changed. if you have been developing a WPF project for a period of time, you may have a clear feeling: how to assign programmers and artists to work on the View layer building. before proceeding, you can refer to my previous article "between UI Designer and Developer ". in the past, our team used the "integration model", and I used part-time roles of "Integrator. this is not bad. but to be honest, this is just a temporary scheme that has to be done in special circumstances. So we have made a lot of effort to start to switch to the "Harvest mode". We have to switch to this mode, at least two basic conditions are required:
(1) You have an artist who can skillfully use tools such as Blend to output XAML to programmers. He focuses on pure UI/UE, and he must also have a certain "programmer" thinking. so that the output can run well as a part of the program, rather than just "looks" like that.
(2) You need a programmer who can break away from the View layer but still write high-quality code.
Fortunately, we are trying to create condition 1 and have achieved good results. (you can recruit an artist who has experience writing Flash scripts and has great enthusiasm for learning, and perform Blend training on him ). the MVVM mode provides great convenience for us to implement the second condition. why does the MVC/MVP Mode fail while MVVM does? In MVC and MVP modes, the View layer has a lot of code logic. The View layer is developed by programmers. Although the UI/UE team will do a lot of work, however, the "implementer" on this layer is still a programmer. in the past development, it worked very well, while in WPF development, programmers were not able to display the View layer, although the artist (referring to the artist who met the preceding condition 1) was very good, but he would say, "Unfortunately, I won't program ". therefore, we need a way to extract the code logic of the View layer, and the View layer is pure so that the artist can create it completely. correspondingly, the corresponding logic of the View layer needs to be extracted to a code layer so that programmers can focus on it.
In retrospect, we only need to write some code (C #) behind View (Xaml #), it is nothing more than to transfer some data and process the data when the data is transferred or perform some operations when the user interacts with the interface control, the simplest example is that in MVC, when the interface is interactive, View calls a method in Controler to pass the corresponding "indication" of the operation to "background. in previous technologies, such "cohesion" code is required. in WPF, you can use another technology to "Connect" between layers. This is "Binding" and "Command ", and the "AttachBehavior" we will mention later ". through Binding, we can transmit data; through Command, we can call operations. (The Role of AttachBehavior will be discussed later ). binding and Command can be written in XAML. In this way, the CS files after XAML can be completely discarded or ignored. this kind of XAML file is exactly what the artist needs. the code for Binding and Command definition descriptions and other related information should be put there. Of course, it is not a View, not a Model, but a "ViewModel ". viewModel is customized for this View. It contains Binding information, such as Converter and DataContext for the View Binding, it includes the definition of Command so that the View layer can be used directly. In addition, it is also a variant of Controler, which has to be responsible for business flow scheduling.
As a result, this figure was created, and MVVM was born, as the "Fashion Hero" said.

3. ViewModel and unit test
If you are a programmer who is using the MVVM mode to build software, I advise you to forget the View as soon as possible. what you are facing is this pattern "UnitTest-ViewModel-Model" (this is not a pattern, it is just something that I have expressed for the moment to elaborate on my point of view ).
I remember that there was a Model-View-AbstractView mode, while the VM in MVVM is actually a AbstractView: the actual action of view. it is an abstract View, with the soul of a View, without the corresponding visual controls. therefore, for programmers, creating such an abstract VM can be considered as creating a View layer. after the artist completes the actual View composed of countless controls, we can use the binder such as Binding and Command to combine the abstract View with the actual View.
So how do we know whether our VMS work normally before the bonding? Unit test!
Before explaining the importance of Unit testing for ViewModel, I would like to give you a sentence: "View and Unit Test are just two different types of ViewModel consumers" (Josh Smith ). if we regard ViewModel as a producer, both View and Unit Test have the same status as consumers. unitTest has a higher consumption capability than View. or you can simply think that View is just a less recommended test method. therefore, to implement this mode, the unit test on ViewModel is necessary, and this test does not depend on any UI control. (isn't the development that does not correspond to ViewModel? Should it be driven by testing? TDD ?)

4, AttachBehavior
Generally, the combination of View and ViewModel works well by using the WPF features such as Command, Binding, and AttachProperty. suppose we have a Button. When the Button is clicked, we need to complete some operations. It is very easy to encapsulate the operation into a Command and bind it to the Button, but what if we want to perform other operations when the Button is loaded? Because the Button is not directly triggered by the Load event, the Command cannot be used. you cannot directly write the Load event processor in the CS file corresponding to the Xaml where the Button is located. This is in conflict with the MVVM design. A bad solution is to inherit the Button and write a Command triggered by Load, which is feasible but obviously not good. just as a control does not have a property and uses AttachProperty without inheritance, we can use AttachBehavior. attachBehavior is not a WPF feature. It is just a best practice and a Pattern. for more information about how to write the AttachBehavior syntax, see: http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx