Model transformation brought about by Continuous decoupling of the presentation layer MVC MVP VM

Document directory

• Three major issues on the user interface: State, logic, and Synchronization)

--- Team and software technology changes brought about by Microsoft WPF

Model-View-viewmodel is an architectural model mainly used in WPF, Silverlight, and WP7 development. It aims to remove almost all code hiding (Code-behind) from the view layer ). Interaction designers can focus on expressing user experience requirements using XAML, and then create and bind the view model, while the view model is developed and maintained by application developers.

Mvvm is a more common implementation of the presentation mode. The mvvm view model includes a conceptual model rather than a data model. All business logic and other operations are completed in the model and view model.

Mvvm encapsulates the status and behavior of the application and isolates the user interface and user experience, so that the designer and the developer can work independently and collaborate easily. Developers can quickly invest in code development and focus only on application logic. If you implement some applications that are relatively small and will not change much in the future, you may not focus on the design pattern, but use the design pattern brings complexity. However, viewmodel has good scalability, which can also bring huge benefits to small applications. It also makes it easy to use the initial build prototype system in the final application, makingAsynchronousProgramming becomes simple.

In MVP mode, designers add an interface between the UI Layer and the logic layer to enable the UI Layer to be separated from the logic layer. Both UI developers and data developers must respect this contract and follow it for design and development. In this way, the same set of data logic can be used in both web UI and window UI.

 

The biggest problem related to the user interface is a large amount of messy code,

A) The user interface contains the responsible logic for maintaining interface objects;

B) Maintenance of application status;

Presentation patternsHow to remove the complexity of the user interface to make the interface more concise and manageableThe results are the types and classifications of common presentation modes:

(1) MVC: Model-View-controller, which forcibly separates input, processing, and output of applications.

(2) MVP: Model-View-presentation class (Model-View-presenter)

(3) mvvm: Model-View-view model (Model-View-viewmodel)

 

 

 

(A) Development Process: MVC-> MVP-> mvvm

(B) MVC-> MVP

(C) MVC, MVP-> mvvm

Three major issues on the user interface: State, logic, and Synchronization)

• Status: status is one of the most important issues on the user interface. The status is the current snapshot of user interface data. In a web application, it may be a session-level variable. In a Windows application, it may only be interface-level data. The more states a user interface contains, the more complex the user interface is.
• Logic: a user interface usually contains interface logic, such as maintaining a text box, a combo box, or any other interface element. The more logic a user interface has, the more complicated the user interface is.
• Synchronization: the user interface usually needs to work with business components. Therefore, the user interface needs to synchronize data between interface elements and Business Objects. If the user interface contains more synchronization tasks, the more complex the user interface is.

	MVC		MVP		Mvvm
	V	C	V	P	V	VM
Status	√		√			√
Logic		√		√		√
Synchronization		√		√	√

Presentation Design Pattern)

The presentation design pattern helps solve the problems listed above. Its basic logic is to create an additional presentation class (presenter) to digest the complex logic, data, and synchronization issues on the user interface, this makes the user interface simple and clear. Depending on the number of responsibilities of this class, it determines the type of the presentation design model, which may be SC, PV, PM, etc. That is to say, the maturity of this class determines that it will be the design model.

Presentation Model (pm)

1. · Presentation class inclusion Logic
2. · Presentation class inclusion status
3. · The presentation class represents an abstract user interface.
4. · The presentation class does not focus on the user interface
5. · View focus class
6. · The View and business model are completely isolated.

 

 Mvvm 

• Inherited self-representation model
• Use the binding mechanism of WPF and Silverlight

MVC 

• No presentation class, Controller)
• The request first arrives at the Controller
• The Controller is responsible for binding views and business models
• The logic exists in the controller.

What is mvvm?

Mvvm originated from WPF and is mainly used to separate the application interface layer and business logic layer. The previous ASP. NET three-tier architecture was Web architecture, while mvvm was a Windows application architecture. WPF uses XAML to draw an interface. The drawn interface is an independent file that contains all the styles and actions on the interface (behavior is an encapsulation of action ).

Why mvvm

Mvvm is actually a three-tier architecture. The m layer (model entity layer) and V layer (view presentation layer, which has the datacontext attribute. This attribute can be used to bind data on the VM layer to display data using the datatemplate template) and VM layer (viewmodel layer, which performs crud operations on the model layer, and provides data binding for the V Layer ).

 

Command object

Talking about messages 

 Triggers, actions, behaviors

　　

 

 

 

 

 

 

 

Traditional winform and ASP.. NET applications are developed based on event-driven, with ASP. for example, in actual development ,*. the ASPX page is used to render HTML ,*. aspx. CS pages are used to implement server logic. This method is convenient and quick at the early stage of development, but this high coupling leads to the complexity of maintenance in the future. Once aspx changes, aspx. the CS code needs to be changed at the same time. For example, replace the gridview control in aspx with the formview control and the corresponding Aspx. the CS file has to be modified in large quantities. The reason why the mvvm mode is widely used in WPF/SL applications is that the WPF/siverlight applications are developed based on data drivers, researchers on the Internet compared mvvm mode with WPF in winform, and concluded that the development efficiency of mvvm mode is very low in a large scale in the winform project.

Unlike MVC and MVPs, mvvm is introduced not only because of technical decoupling to cope with changes, but also because of the change in the development mode of Software Teams..

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 previous development, it worked very well, but inWPFUnder developmentProgrammers cannot display the view layer.Now,Although the artist is good at it, he will say, "Unfortunately, I won't program it ".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.

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 other technologies to connect layers, such as binding, command, and attachbehavior ". through binding, we can transmit data; through command, we can call operations. 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 that defines binding and command and other related information It 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 must be responsible for the scheduling of business processes.

Mvvm mode is applied in WPF/Silverlight. View is mainly used for interface presentation, viewmodel is used for logical implementation, model is used for data construction, and the three can communicate, the most important thing is to use the powerful data binding mechanism in WPF/Silverlight to effectively associate view and viewmodel.

Although the name of the mvvm mode does not reflect the command, in actual situations, command is a crucial part of mvvm implementation. Currently, the project mainly uses the delegatecommand <t> class in the prism framework.

The advantages of using the mvvm mode in the Silverlight project are obvious:

1. Separation of view-logic facilitates the extension and maintenance of the original functions in the future. When the UI changes, the logic in viewmodel does not need to be changed.

2. Simple functions can be implemented through blend without writing any code.

In the implementation process, do not just implement mvvm and mvvm, but make a trade-off based on the actual situation. In fact, because Silverlight is only a subset of WPF, its support for the mvvm mode is still lacking in some aspects:

1. It is difficult to bind an enumeration type, for example, to radiobutton.

2 In silverlight4, the command attribute is only implemented for controls that inherit the buttonbase. In actual use, invokecommandaction in blend4 can be used for other events.

3. You cannot pass complex objects in view and viewmodel. You can destroy view or viewmodel as a compromise, for example, the objects in childwindow and parent container are transmitted.

There are many mvvm frameworks that can do this, some of which are:

Open-source

• Prism: provided by Microsoft and used together with MEF/unity for dependency injection. It supports combined commands and can be expanded. There are detailed tutorials and drills on msdn.
• Mvvm light Toolkit: templates for projects and items with Visual Studio and expression blend. For more information, see here. For more information, see the use of Vs and expression blend.
• Caliburn micro: supports two development modes: viewmodel-first and view-first. It supports asynchronous programming through co-routine.
• Simple mvvm Toolkit: Provides vs project and item templates and dependency injection. It supports deep copy and attribute association between models and view models.
• Catel: templates containing projects and items, user controls, and enterprise class libraries. Supports dynamic view model injection and delayed loading and verification of view models. It also supports WP7-specific view model services.

Closed source

• Intersoft clientui: paid, only supports WPF and Silverlight. However, in addition to the mvvm framework, it also provides other features.
• Vidyano: free but not open-source. With object ing/virtual Persistent Object (Data container), business rules, and built-in ACL-based security features.

To learn about mvvm, refer to the following materials:

• Laurent Bugnion's understanding mvvm pattern and deep dive mvvm
• Microsoft's understanding the mvvm pattern in Silverlight applications
• Erik Lebel gave a speech titled presentation pattern in infoq.

One of the biggest advantages of using mvvm is separation of focus so that users can experience the parallel work of designers and application developers. On the other hand, related concerns include the feeling that it is a bit cool for simple UI operations, the difficulty of debugging data binding, and the performance problems caused by the extensive use of data binding.

Jonathan Allen mentioned in his comment the following symptoms of using mvvm:

1. Your model and view model have the same name.

The view model should not be a packaging of the model. The role of the view model is the request mediation of external services, such as loading and storing data. Data itself, as well as verification and most business logic should be placed in the model.

I often emphasize this. Every time you create a view model to wrap a model, you introduce a huge vulnerability in your API. Specifically, anything that directly references this model may change an attribute in a way that the view model cannot perceive, so the UI will not change accordingly. Similarly, any changes to the calculated fields in the model are not returned to the view model.

2. Your view and view model have the same name.

Ideally, view models do not know how to use them. In particular, WPF applications have multiple Windows sharing the same view model.

For small applications, the entire application may require only one view model. For large applications, the main function may require a view model, and each secondary aspect also needs one, such as configuration management.

3. You have no code to hide.

Code hiding is neither a good thing nor a bad thing. It is just a place for storing the logic related to views or controls. Therefore, when I see a view without any code hidden, I will immediately check whether the following problems exist:

• Does the view model have access to specific controls by name?
• Does the view model access the control through command parameters?
• Does eventtocommand or other behavior that can cause leakage instead of a simple event handler?

The eventtocommand of mvvm light is very problematic because it will prevent the control from being reclaimed after being removed from the screen.

4. View model listener attribute change notification

If a model has a longer life cycle than the view model that monitors its events, memory leakage may occur. Unlike a view that has an unloaded event, the view model does not have a good solution for lifecycle management. Therefore, if they are associated with an event with a view model that has a longer validity period than they do, the view model will be exposed.

 

Refer:

• MVC: Xerox PARC 1978-79 (1979) by Trygve reenskaug, http://heim.ifi.uio.no /~ Trygver/themes/MVC/mvc-index.html.
• Design Patterns: Elements of reusable object-oriented software (1994) by Erich Gamma, Richard Helm, Ralph Johnson, John vlissides, ISBN 0-201-63361-2
• MVP: Model-View-Presenter: The taligent Programming Model for C ++ and Java (1996) by Mike potel, http://www.wildcrest.com/Potel/Portfolio/mvp.pdf
• Twisting the Triad by Andy Bower, Blair McGlashan, http://www.object-arts.com/papers/TwistingTheTriad.PDF
• Gui ubuntures by Martin Fowler, http://martinfowler.com/eaaDev/uiArchs.html
• Presentation Model (2004) by Martin Fowler, http://www.martinfowler.com/eaaDev/PresentationModel.html
• Introduction to model/View/viewmodel pattern for building WPF apps (2005) by John gossman, http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
• WPF apps with the Model-View-viewmodel design pattern (2009) by Josh Smith, http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

• Model View Controller, Model View presenter, and model view viewmodel design patterns, http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod