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.
You are facing a pattern "UnitTest-ViewModel-Model" (this is not a pattern, only
This is for the time being ).
I remember there was a Model-View-AbstractView mode, while the VM in MVVM is actually
AbstractView: the specific action of view. It is an abstract View with
The soul of the View, instead of having the corresponding visual controls.
An abstract VM can be considered to have completed the creation of the View layer. When the artist completes numerous control groups
After the actual View, we can use a binder such as Binding and Command to extract
And 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 the producer, both View and Unit Test have
Consumers of the same status, and UnitTest has a greater consumption capability than View.
Or you can simply think that View is just a test method that is not very recommended.
After this mode is applied, the unit test of ViewModel is required.
Depends on any UI control. (if it does not correspond to ViewModel development, should it pass the test?
To drive? TDD ?)
4, AttachBehavior
Generally, using the WPF features such as Command, Binding, AttachProperty, View, and
ViewModel works well together. Suppose we have a Button, when this Button is clicked
To complete some operations, it is very simple to encapsulate the operation into a Command and bind it
You can do this on the Button, but if we want to execute another
What about the operation? Because the Button is not directly triggered by the Load event, you cannot use
Command. You cannot directly write the Load event processor in the CS corresponding to the Xaml where the Button is located.
In the file, this is in conflict with the MVVM design we just designed. A bad solution is to inherit
And write a Command triggered by Load. This is feasible, but it is obviously not good.
A control does not have a property and uses AttachProperty without inheritance.
AttachBehavior. AttachBehavior is not a WPF feature.
A Pattern. For details about how to write the AttachBehavior syntax, see:
Http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx