Practice of one-time invoicing Software Architecture (I) -- Overview

I'm glad to start talking about the software architecture again. However, this discussion is different from the MIS System Architecture written at the beginning of. It was previously a theory and now a practice, in addition, the previous theories have been implemented in the actual project, and verification and permissions, low coupling between layers, no need for controls, and so on, in fact, everything can benefit from the soul of this architecture-all data will go through the architectureProgram(We sometimes call the bottom layer, and the bottom layer is the software framework ). Unfortunately, this is still a winform project. If it is web development, many of the details need to be considered. After all, the operating mechanism is different. However, this software is a very successful software, and implements multiple languages, multi-unit and multi-currency.

The coupling between the layers mentioned above, the need for controls and so on (in fact, there are still many) are superficial things that may not be taken into consideration by everyone. From the perspective of architecture, let's look at this problem.

1. What kind of architecture is this? Why?

I saw Master Gao hentang's book "Android Application Framework principles and program development", chapter 2 of the book "source of application framework charm: reverse communication", when I first saw the word "reverse communication", I felt that the author was my friend. Of course, after reading this chapter, I became the speaker of the author, because the author expresses the principle of "reverse communication" and "reverse communication" precisely.

I often think about a problem, that is, in the so-called "three-tier architecture" or "multi-tier architecture", if the low coupling between the presentation layer and the business layer is realized, if developers are allowed to trust their own controls, it is difficult for the software framework to control the software framework. Although it can be obtained, the software framework cannot decide when to obtain the software framework and the role of the control, both winform and webform are event-driven operations. Developers will use the events and event methods of the control to write unknown information, which may result in a large numberCodeRedundancy, high coupling between layers, and inconvenient maintenance are also a waste of time.

To solve these problems, you must first let the software framework complete most of the work, of course, work unrelated to the actual business. If we have a Save button, I hope that when I click this save button, the software framework will automatically call the Save method in the business object without adding events and writing call methods in the actual business form, there are two problems. One is how the software framework knows which business object to call to save the method. This is very simple, as long as the business object has a base class, then implement each interface (such as isavable), and the software framework calls the corresponding interface method by itself. Another question is, where is the data to be stored? It seems that the software framework must be referenced by data entities.

As mentioned above: All data (data in a broad sense) will go through the software framework. So my practice is: declare the objects to be used in the corresponding class of the software framework. For example, the business object will be declared in the base class of the presentation layer, and each form has data, this data is also declared in the base class of the presentation layer, and so on (in fact, there are many attributes declared in the software framework, a total of more than a dozen ), developers need to assign values to the Business Object attribute of the base class of the presentation layer, while data does not need to be assigned values. The software framework calls the interface of data query of the Business Object attribute to obtain data.

In this way, there is still a problem in the software framework: How do controls on the form be declared in the software framework? This is because only when the software framework maintains reference to controls on the form can data be bound, visible and available permissions, verification, and the events they need in a unified manner, this requires the software framework to create its own controls. As for the actual business forms, which controls are displayed are customized from the actual business forms to the software framework (this customization is complicated, I extract this piece as a business appearance layer, through which controls and control behaviors can be customized, which will be detailed later ).

We can see that it is more than just a means to implement this architecture.

It is because all data (data in a broad sense) will pass through the software framework that the software framework can control everything and "reverse communication" can work well.

2. Basic Principles

Here, I classify the forms that will appear in the software into a class, each of which is responsible for a layout (the form is only responsible for layout, internal controls, and so on are completed by the Business appearance Layer ), for example, the list form with a tree (that is, a tree list is displayed on the left, a gridview list on the right, nodes in the tree list are changed, and data in the gridview list is changed ), these forms are inherited from a common form class that contains business appearance attributes and some methods. The actual business form inherits a layout form based on its business needs. It also uses the class in the business appearance layer to create content in each layout area of the form (many controls ), specify a required attribute "field name" for the content (this "field name" will be used to bind data during service appearance running, and you can use this "field name" to index the control) and other optional properties are used to customize the content, behavior, and style of the control.

In this way, the Business appearance layer is the top priority. It is responsible for drawing the interface, scheduling of most interactions, and almost all non-functional requirements (for example, locating the problem after refreshing ). Below is a sketch. The business appearance layer is simply drawn (because the next article will focus on it). To briefly illustrate the problem, only one iselectable interface for the business is provided, in fact, there are many interfaces, such as storage. The business appearance layer depends on all these interfaces to complete interface operations, developers do not need to actively call business objects or interfaces in writing actual business form code.

If you look at it from another angle, the Business appearance layer is not only for the above purpose, it is for the platform (.. net) and a layer of abstraction of components, in another way for developers to program, it also has its own operating mechanism. It also discards the hassle of drag and drop operations, the inconvenience of modification and maintenance (which needs to be set in the designer, but now it may only move the upstream and downstream code), and the form style is not uniform, at the same time, it also shields the use of third-party components (if a third-party component is used in the project, but not everyone in the team is very skilled in using this component, this solution can save a lot of time ).

3. Summary

Common forms are the basic forms of various la S. They declare the business appearance attributes. Subclass can access the business appearance attributes and set their own appearances.

A form derived from a common form is only responsible for layout. Each part of the layout is called an area. All controls in the area are created by the Business appearance layer based on the business appearance attributes.

The business appearance layer creates events based on the Operations customized in the actual form and binds corresponding event methods to complete interaction with business objects.

The interaction with the business object is completed using interfaces. If a Business Object implements an interface, it indicates that it has such capabilities. For example, the isavable interface indicates that the business object can be saved, therefore, we have defined many interfaces.

The next article explains the design of the Business appearance layer and the design of permissions and verification.