Reusable Web System Architecture

This article discusses the Reusable Architecture of Web systems, which is also used in various software systems. Tip: This article consists of three parts: problem, solution overview, and core issues in the architecture. The focus is on the last part. Very experienced readers can directly read the last part. Of course, I suggest you read this article. I sincerely hope that after reading this article, all readers can raise any suggestions, questions, and questions for this article. I would like to express my gratitude for your suggestions and suggestions. (1) ProblemFirst, let's look at some problems caused by architecture design: Problem 1: After the system is developed, you need to add new functional modules and find that you do not know where to start, because the modules to be added have business associations with other modules and require code from many other modules, the code of other modules does not provide good interfaces, there is no hierarchical design, and the interface layer completes all the functions directly. Question 2: After A large system A is developed and runs well, the company decides to develop another system B. The core business of B and A is different, but many basic frameworks and basic modules are similar, how can we reuse those modules of system? Problem 3: system A launched by A company has been tested, but A small Bug is found in the last step, and then handed over to the developer for modification. The developer corrected the Bug, and then directly publish. The customer used this system and found that it was almost useless, except the problem that the developer finally corrected. Question 4: how can we effectively collaborate when a company develops a large system with about 200 software developers in three R & D centers? (2) solution OverviewTo facilitate the discussion, I will discuss the system design and implementation in a virtual scenario. Assume that a company needs to build a project management system, which includes three subsystems: user management subsystem, product management subsystem, and project management subsystem. The user management subsystem is responsible for user login detection and simple permission control. The product management subsystem is responsible for managing product names and versions. The project management subsystem includes project information and progress management. So how can we design this system to achieve the highest scalability, reusability, maintainability, and large-scale development of the system? Let's first explain these requirements: Scalability: You can add other subsystems to this system, such as member management and attendance management. Reusability: Includes interface reuse, business logic reuse, data access code reuse, and direct reuse of a subsystem. Maintainability: After the system is launched, it is easy to locate and modify a Bug without affecting other functions. Large-scale development: a multi-person Collaboration team, how to conduct division of labor and communication, and how to submit and compile code. First, we will think of hierarchical design and module division for this system. The so-called hierarchical design is Horizontal layering, such as common interface layer, logic layer, and data layer. The so-called module division, the project management system is divided into user management sub-systems, product management sub-systems, and project management sub-systems. After the horizontal and vertical modules are divided, the entire system becomes a table-like stuff, and each cell represents a module. For the purpose of reusability design, horizontal modules cannot be referenced from each other, and vertical hierarchical modules cannot be called across layers, except for the data access layer. The architecture design in this scenario is given: the business logic layer is split into two layers, namely BLL Manage and bll eo, Manage layer handles purely business-related, and EO layer processes business implementation, and some simple individual businesses. The Data Access layer is also split into two layers: DAL Data and DAL Access layer. The Data layer adds, deletes, modifies, and queries each table, and the Access layer only performs interaction with the database, for example, execute an SQL statement. After each project is compiled, the generated library file reference is shown in: (3) core issues in the architectureNow, we have to solve several important problems. The first problem we encountered was that a large number of objects on the bll eo layer were used in The BLL Manage layer. In this way, The BLL Manage and bll eo layers will be deeply coupled, there is no way to separate them. How can we decouple them to achieve the purpose that each layer of modules can be reused separately? Current solution: Considering the independent reuse of each module and interaction between layers, it is best to transmit data through interfaces instead of object references. Otherwise, coupling will be high. The second problem we encounter is that in Web System Development, Association queries of tables are often involved, and SQL statements are directly constructed and then executed, in the same way, the correlation and coupling are high. In which module should we do these tasks? Current solution: it involves table join queries and so on, which can be placed on the bll eo layer. This layer will be deeply associated and is generally difficult to reuse. In addition, it will pass through the DAL Data layer and directly interact with the DAL Access layer. The third problem we encountered was that there were many layers of systems. What data structures were used to transmit data between different layers? Are these data structures directly defined in each module of each layer? Or should we create a CommonData database and place it in it all? Current solution: the data structure is defined separately between layers in CommonData, depending on the specific system, each has its own advantages and disadvantages. The fourth problem we have encountered is that there are many layers of systems. How can we ensure the operating efficiency of the system if all the data transmitted before each layer is copied? Current solution: From the Perspective of data security and system stability, interface calls and data transmission between databases are generally copied. If there are many layers and the data copy scheme is not feasible, consider several other schemes, taking the EO and Manage layers as examples. Solution 1: the EO layer needs to provide data for the Manage layer. The EO layer manages the data lifecycle. The Manage layer uses data by reference. When the EO layer deletes data, the caller is notified. The notification method is to be determined. Solution 2: the EO layer needs to provide data for the Manage layer. The EO layer manages the data lifecycle. The Manage layer uses data by reference, the EO layer provides the data deletion right to its callers, which can be achieved through the smart pointer reference counting method. The COM technology is also useful, and the Manage layer manages reference counting. Solution 3: send data in multiple layers. For example, if there are a total of five layers, but only the data is copied at the top layer, the other layer only references the data. For example, if data is transmitted from layer A, it must be finally transmitted to the E layer for use, and copied and used in the E layer. The problem with this solution is that if the middle layers of B, C, and D are determined to only transmit references without copying data, then the modules of B, C, and D will not be copied separately, in this way, there will be many potential hazards. To sum up, solution 2 is a better solution. Following the above architecture, we also need to pay attention to the following points to achieve our goal: (1) The definition of each library interface must be clearly given, which is a constraint that must be followed. The advantage of doing so is that, if the constraints are not followed, the Code cannot be compiled and the program cannot run. I would like to express my sincere gratitude to Li ** and Guo * for their suggestions and amendments to this article, especially for many valuable suggestions.