A Discussion on using MVC to improve GUI application development

He discussed a technical issue with the hunter before leaving work yesterday. Today, Ling Hu saw this solution, pointing out that it is a solution that is designed to cure the problem:

But if you directly retrieve the activecontrol of the parent, isn't this form wrong when it is not embedded into other forms? In other words, this form is coupled with its use environment. Is there a better way to solve this problem?

I have mentioned three methods. The first two methods are not common methods. The third is the MVC pattern I mentioned in "Miscellaneous but not refined. At this point, I reached an agreement with linhu. MVC can be used to solve the issue of hunters, and this part of functions can be removed from view to control.

For MVC, Ling Hu has a description:

MVC concept I mentioned in my blog. Simply put, the interfaces and functions that need to be completed, and the data objects to be operated by these functions are all separated. In this way, for example, if you have a button on the interface and a menu to complete the same function, you only need to call the same method in the function class, and it has nothing to do with the button and the interface where the menu is located.

VCL has an action concept, but it is far from enough to support MVC development. This is also a question I have been thinking about, as I have long wanted to write an article, but I feel that my thoughts are not mature enough. Now that we have discussed it, let's talk about it briefly.

Rad makes people develop many bad habits. For example, even if there is an action like this, making MVC will be nondescribable, and the coupling between V and C will be very high, which is very bad. What I imagine is that rad only performs the V Part and completely disconnects the C part, so that the GUI application will become testable and cover the C and M with unit tests.

Ling Hu pointed out a possible problem:

I used to think about the problem of VCL. I think it is because VCL does not support MVC well. Because VCL has integrated C into the control itself, it is very difficult for you to strip it out. I used to write a MVC demo on csdn and encountered this problem.
For example, tmemo lines stores the content of memo, which is related to the operations of tmemo itself. At that time, I used a list.
Record data, but this will lead to duplication of lines and my own data, and there is a potential for non-synchronization. Later, my solution was to give up lines completely.
After the list is updated, clear the lines and reset them. However, this will affect the display effect.

But I think it can still be separated. This has little to do with VCL. I tried to use the MVC idea in the GUI part of a recently written blog backup program. As for the problems mentioned above, you can also solve them.

Memo
The lines attribute of is a tstrings *. Maintain a tstring * in control *
The member points to the lines of memo, and the control directly maintains the lines of memo, so that there is no issue in duplicate. Because the lines attribute of memo is unavailable
Changed, so you can only operate through control. However, other code in the program cannot directly operate on the lines of memo, but must be executed through control.

Summarize my ideas as follows:

I simplified the relationship between V and C into three types: Action, State, and contraint.
Action indicates an operation on the interface, and calls the corresponding function of control for processing.
State indicates a change in the interface status, which is executed by control.
Constraint indicates the constraint, that is, the association between action and State. For example, an action cannot appear in a certain state.
This constriant has two types, strong constraints and weak constraints.
Weak constraints can be implemented in view
Strong constraints may be implemented in control or model.

It is necessary to add: the idea of constraint was first inspired by discussions with chechy last year on an XML-based framework.

In fact, there are few weak constraints. Generally, they cannot be counted as part of the business logic. For the sake of simplicity, they are implemented on the view side. As Ling Hu said, weak constraints refer to disable controls or invisible controls. However, some disable/invisible may need to be put into control.

Ling Hu summarized the following:

Use
User performs an operation on the Interface Element, sends a request, actually triggers a control event, this event will call control, control continues to call the business module, business module
Complete the actual business logic and return the result. Based on the returned value, Control performs two possible operations: Turning to another page or changing some states of the current page (or both ); the controls on the page are composed
The View class is responsible for modifying the actual display form of the control after the View class receives the status change.

The entire process is:
View's
Event-> Process Control-> business control-> model-> Model
Return-> business control return-> process cotrol's state change or
Open New View-> View class (change form's control)

This is basically the case. In this case, the view layer can be easily changed. For example, move from PC to PDA or to web.

Ling Hu added:

This
The view layer consists of form and View class. form is responsible for visualization, receiving user events, and view
Class is responsible for handling changes in status. Then, your so-called strong constraint can almost certainly be implemented in Process Control or business
Control layer; and weak constraints, almost certainly in view class

If you consider the change of the view layer, you must add the View class, which I did not consider at first. I originally imagined that this part of the function is in control. So there are still many immature areas that need further discussion. The most important thing is that it must be tested by practice.

Ling Hu raised two important questions:

1. Windows controls sometimes lead to logic processing on the interface. For example, in checkbox, the interface directly changes the status, but the backend logic processing may modify the status again.
2. There is a more serious problem. Modifying the status or content of some controls will trigger some events, which will cause recursive calls of some events or difficult control of some events.
In traditional web programs, this problem is not obvious, because the operations you perform on the view will not have actual impact, and the MVC process will not be performed on the server until the submit is executed, but the client is not that simple, and every operation may run in this way.

In fact, these two problems exist in traditional rad development, especially the second problem, which is particularly serious and difficult to solve. I initially considered using the MVC mode in GUI application development. One important reason is to solve the second problem above.

Pair
The first problem is as follows: an action is generated during check, which can be handled based on the situation when called to control. If you know that this is a model that requires a long time
You can change the interface status first, for example, set the cursor to Hourglass, update the checkbox status after the model processing is complete, and restore the cursor. Of course, the final shape
The State depends on the processing result of the model, and the state of the view is updated by the control.

The solution to the second problem is that all events will be converted to the control action request. When the first request reaches the control, the related constraint will be started. Subsequent requests will have different effects based on constraint-for example, some will be blocked.

Ling Hu raised the third technical question: how to transmit the environmental context

This problem is better solved in GUI applications, but it is troublesome in Web applications. In GUI applications, context can be recorded in control directly or indirectly (by pointing to control properties in view, such as the lines mentioned above. However, because web applications are stateless, additional persistence mechanisms are required.

Ling Hu said: persistence mechanisms can be achieved on the server side by using databases and cookies on the client side.

However, the implementation method must be different from that of GUI applications.

My pilot program did not implement all of the above. I tried the separation of V and C, so I had to consider it again.

I agree with Ling HU: Let's see if the implementation is more practical. Otherwise, it is empty or empty. Try to use the above theory to implement it. It would be better if it can be upgraded to the framework. Even if it's just a good idea, some problems need to be realized before discussion.

It is still difficult to upgrade to the Framework. My goal is to organize a set of practical practices to improve GUI application development.