1 layer 2 and layer 3 C/S architecture style

C/S architecture is based on resource inequality, and put forward for the realization of sharing, is a mature technology in the 1990s, C/S structure divides the application into two parts, server (background) responsible for data management, client (foreground) to complete the task of interaction with users.

C/S software architecture has powerful data operation and transaction processing ability, simple model idea, easy to understand and accept. However, with the expansion of enterprise scale and the increasing complexity of software, the traditional two-layer C/S structure has the following limitations:

  1. The Layer 2 C/S structure is a single server centered on LAN, so it is difficult to expand to large enterprise WAN or Internet.
  2. The combination and integration ability of software and hardware is limited;
  3. The server load is too heavy, it is difficult to manage a large number of clients, the system performance is easy to deteriorate;
  4. Poor data security. Because the client program can access the database server directly, other programs on the client computer can also try to access the database server, thereby compromising the security of the database.

It is because of the two layer C/S has so many disadvantages, therefore, the three layer C/S structure emerged. The three-layer C/S structure divides application functions into three parts: presentation layer, function layer and data layer, as shown in Figure 1.

  1. Presentation layer is the user interface part of the application, which is responsible for the dialogue between users and applications. It is used to examine data entered by the user from the keyboard, etc., and display data output from the application. When changing the user interface, you only need to rewrite the display control and data checker without affecting the other two layers. The content of the check is also limited to the form and value range of the data, not the processing logic of the business itself.
  2. The functional layer is equivalent to the application ontology, which is the specific business processing logic into the program. The data needed for processing is retrieved from the presentation layer or data layer. The data interaction between the presentation layer and the functional layer should be as simple as possible.
  3. The data layer is the database management system, responsible for the management of the database data read and write. Database management systems must be able to perform rapid updates and retrieval of large amounts of data. As a result, most requests to move from the functional layer to the data layer use the SQL language.

The solution to the three-tier C/S is to split the three tiers unambiguously and logically. The original data layer has been separated as a database management system, so the key is to separate the presentation layer and the functional layer into separate programs and keep the interface between the two layers clean.

It is generally the case that only the presentation layer is configured in the client, and if the function layer is also placed in the client, the program is much more maintainable than a layer 2 C/S architecture, but other issues are not addressed.

The client is overloaded and the data needed for business processing must be transferred from the server to the client, so the system performance is prone to deteriorate. If the functional layer and the data layer are placed separately on different servers, data will also be transferred from server to server. However, because the three layers are placed on different hardware systems in this configuration, they are flexible enough to accommodate the increase in the number of clients and changes in the handling load. For example, when a new business process is appended, servers that load the functionality layer can be added accordingly. Therefore, the larger the system scale, the more significant the advantages of this form.

B/S architecture style

In a three-tier C/S architecture, the presentation layer is responsible for processing user input and output to the customer (for efficiency reasons, it may validate user input before it is transmitted up). The functional layer is responsible for establishing the connection of the database, generating SQL statements to access the database according to the user’s request, and returning the results to the client. The data layer is responsible for the actual database storage and retrieval, responds to data processing requests from the functional layer, and returns the results to the functional layer.

Browser/Server (B/S for short) style is an implementation of the above three-layer application structure, its specific structure is: Browser/Web Server/database Server. The basic framework of computer application system using B/S structure is shown in Figure 2.

In B/S structure, in addition to the database server, the application program is stored on the Web server in the form of Web pages. When users run an application program, they only need to enter the corresponding URL in the browser on the client, call the application program on the Web server and operate the database to complete the corresponding data processing work. Finally, the results are displayed to the user through the browser.

It can be said that in the COMPUTER application system of B/S mode, the application (program) has the centralized characteristic to a certain extent. Based on B/S architecture, system installation, modification and maintenance are all solved on the server. Users in the use of the system, only need a browser can run all modules, really achieve the “zero client” function, easy to run automatic upgrade.

B/S architecture also provides the most realistic open foundation for the interconnection, networking and unified service of heterogeneous machine, heterogeneous network and heterogeneous application service. Before B/S structure appeared, the functional coverage of management information system was mainly within the organization. The “zero client” approach of the B/S structure enables the organization’s suppliers and customers (which may be potential, that is, may be unknown in advance! Computer easily become a management information system of the client, and then in a limited amount of functions within the scope of the query information organization, complete with the organization’s data exchange and processing of various business work, expanding the organization function of computer application system covering range, can make full use of various resources on the network, application maintenance work is also greatly reduced.

In addition, the combination of B/S structure computer application system and Internet also makes the realization of some new enterprise computer applications (such as e-commerce, customer relationship management) become possible.

Compared with C/S architecture, B/S architecture also has many shortcomings, such as: (1) B/S architecture lacks the ability to support dynamic pages, does not integrate effective database processing functions. (2) The response speed of application system using B/S architecture is much lower than that of C/S architecture in data query. (3) Data submission in B/S architecture is generally based on pages, and the dynamic interaction of data is not strong, which is not conducive to the application of OnLine Transaction Processing (OLTP).

3 MVC Architecture Style

The full name of MVC is Model View Controller, which is the abbreviation of Model – View – Controller. It is a kind of layered architecture style. MVC is a software architecture pattern proposed by TrygveM.H. Reenskau, a Norwegian computer expert, in 1979. MVC was originally used in SmallTalk.

The basic idea of MVC is separation of concerns. A typical hCI application has three main concerns: the presentation of data on a visual interface, UI processing logic, and business logic. Mixing the three together in the traditional autonomous view model, where uI-related logic is defined on events that target relevant elements of the view, presents a number of problems: (1) Business logic is UI-independent and should be reused to the maximum extent possible. Since the business logic is defined in the autonomous view and is completely bound to the view itself, the processing logic based on the abstract UI can be shared if we can abstract away the behavior of the UI. (2) Business logic is the most stable, UI processing logic is second, and visual interface rendering is the worst (e.g., we often tweak HTML for better rendering). If elements with different stability are combined, the element with the worst stability determines the stability of the whole. (3) Any component that involves UI is not easy to test. The UI is presented to humans and is intended for human-computer interaction. It is not easy to automate testing components using machines that simulate a live human being, and the autonomous view seriously compromises the teachability of components.

To solve these problems, we need to adopt a separation of concerns approach to separate visual interface presentation, UI processing logic, and business logic, and to interact in a way that minimizes their dependencies.

The division of labor and collaboration of various parts in MVC is as follows: (1) Model is the encapsulation of application state and business functions, which can be understood as a domain Model containing both data and behavior. The Model accepts the Controller’s request and performs the corresponding business processing, notifying the View when the state changes. (2) View presents the visual interface and captures the end user’s interactive operations (such as mouse and keyboard operations). (3) After the View captures the user interaction, it will directly forward it to the Controller, which will complete the corresponding UI logic. If calls involving business functions are needed, the Controller calls the Model directly. After completing the UI processing, the Controller controls the original View or creates a new View as needed in response to user interaction.

The basic structure of the MVC pattern is shown in Figure 3.

4. MVP architecture Style

MVP stands for model-view-Presenter. Model provides data, View displays, and Controller/Presenter handles logic.

MVP evolved from the classic MVC pattern. Their basic ideas are similar: Controller/Presenter handles logic processing, Model provides data, and View displays.

Of course, THERE are some notable differences between MVPS and MVC. The “chaotic” interaction between elements in THE MVC mode is mainly reflected in allowing the View and Model to “communicate” directly, which is not allowed in the MVP mode. In MVP, views don’t use the Model directly, they communicate with each other through the Presenter (Controller in MVC), all interaction happens inside the Presenter, Whereas in MVC, the View will read directly from the Model instead of going through the Controller.

MVP not only avoids coupling between View and Model, but also further reduces the dependency of presenters on views. Presenter relies on an abstract View, the interface that the View implements, I View, which has the most immediate benefit of making the UI processing logic defined in Presenter easier to test.

Since Presenter’s dependency on the View is defined in the INTERFACE I View, we only need a View that implements this interface to test Presenter. The MVP structure is shown in Figure 4.

Here’s a look at the pros and cons of MVP.

The advantages of MVP include: (1) The model is completely separated from the view, and we can modify the view without affecting the model. (2) Models can be used more efficiently because all interaction takes place in one place — inside the Presenter. (3) We can use a Presenter for multiple views without changing the Presenter logic. This feature is useful because the view changes more frequently than the model. (4) If we put the logic in Presenter, we can test it out of the user interface (unit tests).

The disadvantages of the MVP include that the view interacts with the Presenter too often because the rendering of the view is in the Presenter. It is also important to understand that if a Presenter renders too much of a view, it tends to tie it too closely to a particular view. If the view needs to change, the Presenter needs to change too. For example, if a Presenter that was originally used to render HTML now needs to be used to render PDF, the view will probably need to change as well.