Architecture Evolution of message prompts-theoretical part

A project is an Internet application. Assume that the project has different user groups. The front-end of each user group is an independent project, which is handed over to different developers for development. The frontend and backend interaction modes are WebService. In the interaction between the frontend and backend, there are two main types of operations: Query, including returning a single record and returning a collection; and command, including adding, deleting, and updating. Of course, a single operation may also be a combination of several command requests. For the first type of operation, data must be returned for display. If no data is returned, no matching data is found. The second type of operation generally affects the persistent data at the backend. The result of the operation must be returned, whether it is successful or failed, or what should I do? The message discussed today is the result of the Operation returned by the backend. The design of this type of message is mainly related to the processing and display of this message in the previous section. At the beginning, there was no design. The developers of each project designed their own message format, prompt content, and UI display. Some use alert in the browser, some use the message prompt box in the front-end framework, and some use both prompts in a project. Most of the prompts are interaction with the backend. After obtaining the results, a new message box is displayed. The prompt content is also hardcoded in the new message box and initialized using the constructor ). Of course, at the beginning, everyone had to fight for each other, and they did not care about these things when they stepped up their time to catch up on the construction period. At the conclusion of the first iteration cycle, we raised this question and made a summary. The above practices may cause the following problems.

• The hard encoding of the message content. Multiple messages of the same type, such as prompts that the operation is successful). If you change the content of this type, you need to modify it in many places, which is almost miserable.
• The initialization of the message box is scattered in various areas that interact with the background. If you need to change the UI of the message box, it will also cause modifications in multiple places, which is already miserable.
• The logic code of the message is mixed with the UI display code without separation, leading to the failure of unit testing.

We have discussed the problem above and can improve it through the reconstruction below.

• First, sort messages to facilitate subsequent processing.
• For hard coding, content of the same type is centrally managed based on the type to reuse and facilitate later maintenance.
• Centralized management of message box initialization can also facilitate changes to the message box UI, which can be solved by introducing the factory mode.
• Separate the message logic and UI display code to facilitate unit testing and UI changes.
• Create a message center to centrally manage the initialization of message boxes and display of messages.

The purpose of this operation is as follows:

• Independent Message Processing
• Public Message Processing
• Separate message processing logic and message content UI display
• Centralized Message Management

After sorting, messages are divided into the following categories:

• Successful. Complete a request correctly.
• Prompt. When the request is completed, the request cannot be completed correctly due to the lack of necessary conditions or changes in some conditions.
• Exception. An exception occurred when the request was completed, including code exceptions and network exceptions.

In the subsequent implementation, we are going to introduce interface-oriented programming to interface the message center and message processing to facilitate future replacement. The message box initialization introduces the factory mode to implement centralized initialization management, isolate the message box title, prompt content, button operations) and message box UI display, reserve space for future UI changes. We will discuss the implementation and code here. If you have any better suggestions, please leave me a message later. Thank you for your participation !!!

This article is from the "breakthrough IT architects" blog, please be sure to keep this source http://virusswb.blog.51cto.com/115214/685995