Simplified mvvm Design Patterns

Mvvm Essentials

1 model: Abstraction of realistic objects. It is generally summarized as the attributes of these attributes.

2 viewmodel: it is a data communication class of XAML on a beautiful interface. View is to find the corresponding binding data from the viewmodel class.
The basic naming rule of viewmodel is that the name of the View Interface is suffixed with the viewmodel (mainwindowviewmodel) and the viewmodel

To expose the attribute binding required for all view pages and the commandbinding operation. All page operations should be implemented in viewmodel

The commandbinding action. To make binding take effect, all viewmodel classes should be implemented

Inotifypropertychanged interface. Generally, a viewmodel base class is defined to inherit the interface.

The viewmodel class inherits the custom base class to notify the binding attribute change.

/// <Summary> /// viewmodel base class that implements the inotifypropertychanged interface with the property change notification. /// </Summary> public class notificationobject: inotifypropertychanged {public event propertychangedeventhandler propertychanged; // <summary> /// encapsulate propertychangedeventhandler. /// </Summary> /// <Param name = "propertyname"> </param> Public void raisepropertychanged (string propertyname) {If (this. propertychanged! = NULL) {This. propertychanged. Invoke (this, new propertychangedeventargs (propertyname ));}}}

 

Most programmers like elegant code, and hard coding ("propertyname") is as rare as possible.
Therefore, the relatively elegant method should be implemented as follows:

/// <Summary> // notificationobject elegant extension __^ // </Summary> Public static class notificationobjectex {public static void raisepropertychanged <t, tproperty> (this t notificationobject, expression <func <t, tproperty> Expression) where T: icationicationobject {var memberexpression = expression. body as memberexpression; If (memberexpression! = NULL) {string propertyname = memberexpression. member. Name; icationicationobject. raisepropertychanged (propertyname);} else {Throw new notimplementedexception ();}}}

In this way, when attributes are exposed in viewmodel, they can be written as follows:

        private double input1;        public double Input1        {            get { return input1; }            set            {                if (input1 == value) return;                input1 = value;                this.RaisePropertyChanged(p => p.Input1);            }        }

Use this. raisepropertychanged (P => P. input1); to replace this. raisepropertychanged ("input1"); errors are often caused by hard coding...
Of course, there is another way to solve the problem: Use a custom snippet and implement it using a code segment.

3. view is the page. View is the attribute exposed from viewmodel. Use binding to achieve decoupling.

 

The main thing is to abstract the model first. Then, enrich the viewmodel according to the View Interface operation requirements. This is the main idea of mvvm. Why do you still feel that it is always so hard to apply it to practice?

Mvvmlight and simplemvvm don't want to worry about it. I want to knock it out by hand...

How to Learn next? Kneel down to the top.