Shulou(Shulou.com)06/01 Report--

This article mainly explains "what knowledge points does AWTK-MVVM have". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what knowledge points does AWTK-MVVM have"?

1.1 Separation of user interface and business logic

It is common sense for every programmer to separate the user interface from the business logic when developing an application. Separating the user interface from the business logic has several important benefits:

It helps to isolate changes. The user interface is the most easy to change, the improvement of ease of use, the beautification of appearance and the change of requirements, the first impact is the user interface. If the user interface is coupled with the business logic, the slightest change in the interface will lead to a series of code changes, which will not only increase the cost and cycle of development, but also very boring. Let programmers' happiness plummet.

It is beneficial to automatic testing. The earlier the BUG in the code is discovered, the lower the cost of modification, and unit testing is an important means of discovering BUG at an early stage. Unit testing is automated, and the investment in writing test code in the early stage will be rewarded by saving testing time later. Unit test code can be accumulated to build a solid firewall for the software, making the whole system more and more stable. The separation of user interface and business logic is an important means to improve the testability of code, which makes it possible to write unit test programs.

It is conducive to division of labor and cooperation. The coupling of the user interface and business logic will make the modification of the user interface very difficult, and the programmer will resist the changes of the user interface and increase the contradiction between the designer and the programmer. After separating the user interface from the business logic, the designer's work can be smoothly output to the programmer, so that the programmer and the designer can live a happy life together.

1.2 how to separate user interface from business logic

Separating the user interface from the business logic, MVVM is the most commonly used mode at present. MVVM did not emerge out of thin air, but evolved from MVC and MVP, each time to solve problems that had not been solved before.

1.2.1 MVC mode

MVC is the abbreviation of Model-View-Controller. For the first time, it divides the system into Model,View and Controller, clearly separating the user interface from the business logic:

Model (Model). Simply put, the model is business logic. We often talk about object-oriented design and modeling, and the model established is the model here, which is an abstraction of business logic in the real world. Object-oriented modeling is to find out which classes are in the business logic and the relationships between these classes. Classes describe the properties and behavior of objects. Classes are design-time concepts and objects are run-time concepts. An object is usually a business entity, and a Model contains one or more business entities. Many people (including some well-known domestic experts) think that the model is data, which is caused by the lack of a thorough understanding of object-oriented design. Objects have both data and behavior, and only data without behavior, it is impossible to make objects collaborate and work together to complete business logic.

View (View). As we all know, this is the interface between the user and the software. For GUI applications, it is windows and dialogs, as well as the various controls above. The view should be said to provide an interface for the user to observe and manipulate the model.

Controller (Controller). The controller is responsible for interpreting the input from the user through devices such as keyboard / mouse and informing the model and view to make corresponding changes. In GUI applications, to put it bluntly, it is actually the event handler of the control, which is related to both the interface and the model. It takes data from the interface, then calls the function of the model, and sometimes updates the user interface directly.

Controller (Controller) is not business logic, in theory, it is only a thin glue layer, but many novices write business logic in the controller, resulting in only data left in the model, resulting in the illusion that the controller is business logic and the model is data.

1.2.2 MVP mode

The MVC pattern solves the problem of separating the user interface from the business logic, but there is an important problem that has not been solved: the controller is interface-related, and there is no way to write unit test programs for the controller. In order to solve the above problems, MVP mode arises at the historic moment. MVP is the abbreviation of Model-View-Presenter.

Model (Model). The model is also a model in MVC, and I won't repeat it here.

View (View). The view is still a view in MVC, but it does not need to register a change event notification with the model, which is done by the rendering logic.

Rendering logic (Presenter). Controller becomes Presenter is only a superficial phenomenon, the most important thing is that MVP abstracts the view, the presentation logic is no longer as direct as the controller to access the specific view, but through the interface of the view to access the view, the interface of the view is abstract, there can be different implementations, so it is convenient to Mock out a view, making it possible to write a unit test program to present the logic. Note that the interface of the view here is not generic, and each view has a separate interface, a real implementation, and an implementation for testing Mock.

In theory, the MVP pattern is very complete, it is a good separation of the interface and implementation, but also can write unit test programs for presentation logic. But from an engineering point of view, MVP has a fatal flaw: writing a lot of boring code!

For ease of illustration, let's use an example of editing book information to see what boring code to write. This example is very simple, but it requires a lot of boring code:

1. When initializing, register event handlers for the control, such as the Save button.

two。 During initialization, the book information, such as book title, author and publisher, should be taken out of the model and set to the control of the view one by one. In this process, the data format may need to be converted, such as the publication date. It is an integer in the model and a string in the view, which requires conversion.

3. At the end of editing, the book information, such as book title, author and publisher, should be taken out one by one from the view and saved to the model. In the process, you may need to convert the data format, such as the previous publication date, to convert the strings in the view back to integers in the model.

4.View has an interface definition, a real implementation and an Mock implementation.

The code is simple but boring, and in every module with an interface, it follows the same rule, but it is completely different and has to be rewritten.

1.2.3.MVVM mode

The rules of MVP schema are found out and abstracted, and some rules are used to establish a relationship between the view and the model, that is, data binding and command binding, to form the MVVM schema. MVVM is the abbreviation of Model-View-ViewModel. In MVVM:

Model (Model). The model is also a model in MVC, and I won't repeat it here.

View (View). The view is still a view in MVC, but it does not need to register a change event notification with the model, which is done by the data binding.

View model (ViewModel). ViewModel is neither Controller nor Presenter, is the view model a view or a model? According to John Gossman, the inventor of MVVM, the view model is the model in the view. The bug under the magnifying glass is still a bug, so the model in the view is still the model. The view model is not directly related to the view, and unit tests can be written for it.

Where is the presentation logic Presenter? The rendering logic has changed from line by line of code to rules for data binding and command binding, and the processing and interpretation of the rules have become MVVM frameworks or common libraries that can be shared across multiple projects.

The MVVM mode has the following benefits:

Force the separation of user interface and business logic. In MVC and MVP, the separation of user interface and business logic cannot be enforced, and the programmer's thoughts lead to the mixing of user interface and business logic. There is no need to write interface-related code in MVVM, so there is no way to couple the user interface with business logic.

There is a looser coupling between the interface description file and the program code. XML or RC files are usually used to describe the interface. In MVC and MVP, adding a control or deleting a control in the interface will cause the corresponding code to be modified. In MVVM, using the intention-oriented programming, the interface is only a kind of intention, as for who realizes it, how to realize it, and even whether it is realized or not, the interface does not care, so the coupling between the interface and the code is very loose.

There is no need to learn GUI's API. Establish the relationship between the view and the model through data binding and command binding. Instead of imperative code with declarative rules, there is no need to write interface-related code, so there is no need to learn GUI's API, whether it is Qt or AWTK, are developed in the same way.

The view model is different from the model, and the main reasons for introducing the view model are:

The data in the model is sometimes not suitable to be displayed directly on the view. For example, the publication date, which is an integer in the model, is directly displayed so that the user cannot understand it and needs to be converted into a string that human beings can understand.

A data item in the model may be rendered on the view in multiple forms. For example, the publication date, in addition to showing the publication date, may also show a new book logo for a recently published book.

The format of the input data in the view and the stored data in the model may sometimes be different. For example, for the publication date, the format entered on the view is different from that stored in the model.

The view requires the view model to provide data verification rules to determine whether the input on the view is legal.

Some data are dependent. For example, when entering a shipping address, when you select a province, the list of cities changes.

Some states are not business logic, but need to be saved. In order to support undo operations, you need to save the command history.

There is no way to call the member function of the object through the name of the function, and there is no way to access the member variable of the object through the name of the attribute in the static language such as Cpicket +. The view model needs to provide a mechanism to implement these functions, otherwise binding rules cannot be implemented.

The shortcomings of MVVM.

The problem follows the memory. It is said that WPF costs a lot of memory and is unbearably large even on PC (it is often used against MVVM). WEB front-end popular MVVM frameworks, such as React and Vue.js, use virtual DOM, and memory requirements may increase significantly.

Performance issues. The usual practice for MVVM is to refresh the entire interface when the model changes. If you use the virtual DOM approach, you also need to rebuild a virtual DOM, compared with the original virtual DOM, the performance overhead is even greater.

Debug the problem. Without the assistance of tools, data binding can make debugging difficult.

The above problems are no longer a big problem on mobile phones and PC, but they are still difficult to overcome for embedded systems, so there is almost no MVVM framework for embedded platforms at present.

1.3 AWTK-MVVM

AWTK-MVVM is a set of MVVM framework developed in C language and optimized for embedded platform. It realizes the basic functions such as data binding, command binding and window navigation. Using AWTK-MVVM to develop applications, you don't need to learn the API of AWTK itself, you only need to learn the implementation of binding rules and models.

Compared with other MVVM frameworks, AWTK-MVVM features include:

The code is small.

Core code: about 3000 lines.

AWTK related code: about 700 lines.

Jerryscript related code (optional): about 1700 lines.

High performance. The core code is developed in C language and its performance is not much different from that of using AWTK directly.

Low memory overhead.

A binding rule takes about 150 bytes. If there are 10 binding rules on a window, it takes up 1.5K of memory.

The binding rules in the list can be shared, and the additional memory overhead is small.

Quarantine is more thorough. In AWTK-MVVM, the interface and binding rules are described in XML, and all you need to develop an application is the development model (that is, business logic). Developers do not have the opportunity to access the view directly except through special means.

Easy to debug.

Provides a framework generation tool for the view model to avoid errors caused by handwritten code.

Added LOG information for all kinds of exception handling.

A large number of demo are provided for reference.

Open source, easy to debug.

Support for multilingual development.

C language and JS are currently supported.

New programming languages will be supported as needed in the future.

The various programming languages supported here are completely unrelated to AWTK's scripting binding: here, the application's business logic can be developed in different languages, while AWTK's scripting binding allows applications to use different scripting languages to call AWTK's API.

It can be transplanted to other GUI. AWTK-MVVM is designed for AWTK, but we have isolated the code related to AWTK so that it can be ported to other GUI. The code related to AWTK is only 700 lines long, so it is very easy to migrate to the new GUI. Of course, AWTK can meet common needs, and it just gives developers more choices.

AWTK-MVVM also has some limitations and currently does not support dynamic generation of interface elements, so it can be developed in combination with traditional methods. In the future, AWTK will support popular frameworks at the front end of WEB, such as Reactjs and Vuejs, and will be used in high-end platforms such as mobile phones, Mini Program and desktop programs.

Thank you for your reading, the above is the content of "what knowledge points does AWTK-MVVM have". After the study of this article, I believe you have a deeper understanding of what knowledge points AWTK-MVVM has, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.