Three-tier architecture (not MVC)

Three-tier architecture

Edit

The three-tier architecture (3-tier architecture) typically has a three-tier architecture that divides the entire business application into: the interface layer (User Interface layer), the business logic layer, the data access layer Access layer). The purpose of distinguishing hierarchy is to think of "high cohesion and low coupling". In the design of software architecture, layered structure is the most common and most important structure. Microsoft's recommended layered structure is generally divided into three tiers, from bottom to top: The data access layer, the business logic layer (or also called the domain layer), the presentation layer.

Chinese name

Three-tier architecture

Foreign names

3-tier Architecture

Classification

interface layer, business logic layer, data access layer

Purpose

The idea of "high cohesion, low coupling"

Advantages

Reduce dependency normalization between layers and layers

Disadvantages

Complex system architecture, not suitable for small projects

Directory

1. 13-Layer Structure principle
2. 2 Role of each layer
3. 3 Distinguishing methods
4. ? Presentation Layer

1. ? Business Logic Layer
2. ? Data layer
3. 4 Rules
4. 5 Advantages and Disadvantages

1. ? Advantages
2. ? Disadvantages
3. 6 Differences from MVC

Three-layer structure principle

Edit

In 3 levels, the main functions and business logic of the system are processed in the business logic layer.

The so-called three-tier architecture is the addition of a "middle tier", also called a component layer, between the client and the database. Here the three-layer system, not refers to the physical three layer, not simply placed three machines is three-layer architecture, also not only B/s application is the three-tier architecture, three layer refers to the logic of the three layer, that is, the three layers placed on a machine.

The three-tier application puts business rules, data access, legitimacy checks, etc. into the middle tier for processing. Typically, the client does not interact directly with the database, but instead establishes a connection with the middle tier through com/dcom communication, and then interacts with the database through the middle tier.

The role of each layer

Edit

1: Data access layer: mainly for non-raw data (database or text files, such as the form of data storage) operation layer, rather than the original data, that is, the operation of the database, rather than the data, specifically for the business logic layer or presentation layer to provide data services.

2: Business logic Layer: mainly for the specific problem of operation, can also be understood as the operation of the data layer, the data business logic processing, if the data layer is a building block, the logic layer is the building of these blocks.

3: The interface layer: The main means of the web, can also be expressed as a WinForm way, the web can also be represented as: ASPX, if the logical layer is quite powerful and perfect, no matter how the presentation layer is defined and changed, the logic layer can provide services perfectly.

Distinguishing methods

Edit

1: Data access layer: The main view of the data layer contains no logical processing, in fact, its various functions mainly to complete the operation of the data files. Without having to worry about other operations.

2: Business Logic Layer: mainly responsible for the operation of the data layer. In other words, the operation of some data layers is combined.

3: Presentation layer: The primary request is accepted by the user, and the data is returned, providing the client with access to the application.

Presentation Layer

On the outermost (topmost), closest to the user. Used to display data and receive user input data, to provide users with an interactive interface.

Business Logic Layer

The business logic layer is undoubtedly the part of the system architecture that embodies the core value. Its focus is mainly on the development of business rules, the implementation of business processes and other business requirements related to the system design, that is, it is related to the domain of the system (domain) logic, and many times, the business logic layer is also called the domain layer. For example, Martin Fowler, in the book Patterns of Enterprise application Architecture, divides the entire architecture into three main layers: the presentation layer, the domain layer, and the data source layer. As a pioneer in domain-driven design, Eric Evans has made a more detailed division of the business Logic layer, subdivided into application and domain layers, and further separates application logic from domain logic solutions through layering.

The position of the business logic layer in the architecture is critical, it is in the middle of the data access layer and the presentation layer, which plays the role of connecting link in the data exchange. Since the layer is a weakly coupled structure, the dependencies between layers and layers are downward, and the bottom layer is "ignorant" to the upper layer, and changing the upper-level design has no effect on the bottom of its invocation. If you follow the idea of interface-oriented design in a layered design, this downward dependency should also be a weak dependency. Therefore, without changing the definition of the interface, the ideal layered architecture should be a "drawer" architecture which can be extracted and replaceable. Because of this, the design of the business logic layer is especially critical for a scalable architecture, because it plays two different roles. For the data access layer, it is the caller and, for the presentation layer, it is the callee. Dependency and dependent relationships are entangled in the business logic layer, and how to implement the decoupling of dependencies is a task left to the designer in addition to implementing business logic.

Data layer

Data Access layer: sometimes referred to as the persistence layer, its function is mainly responsible for database access, access to the database system, binary files, text documents or XML documents.

The simple argument is to implement the select,insert,update,delete of the data table. If you want to add an ORM element, it will include the mapping between the object and the data table, and the persistence of the object entity.

Rules

Edit

Three-layer structure of the program is not said to divide the project into Dal,bll,webui three modules called three layers, the following questions in your project:

⒈uilayer There are only a few (or no) SQL statements or stored procedure calls, and these statements guarantee that the data will not be modified?

⒉ If you take uilayer off, can your project provide all the features on the INTERFACE/API level?

⒊ can your dal be ported to other projects of similar environment?

⒋ three modules can be run on different servers separately?

If not all of the answers are yes, then your project is not a strictly three-tier program. The three-tier program has some rules that need to be agreed upon:

⒈ most critical, the UI layer can only be used as a shell and cannot contain any business logic (bizlogic) processing process

⒉ should be designed from the BLL rather than the UI. The BLL layer should implement all bizlogic on the API, in an object-oriented manner

⒊ whether the data layer is a simple sqlhelper, or with mapping classes, should be in a certain degree of abstraction to achieve system-independent

⒋ regardless of whether you use COM + (Enterprise Service), or remoting, or remote object technology such as webservice, regardless of whether the deployment is really deployed to different servers, at least in the design time to do such considerations, further, You also need to consider multiple servers that are clustered by load balancing

So consider whether a project should be applied to the three-layer/multilayer design, first to consider whether it is really necessary? In fact, most programs open a webapplication is enough, there is absolutely no need to do so complex. Multi-layered structures are designed to address the needs of truly complex projects.

Advantages and Disadvantages

Edit

Advantages

1, the developer can only focus on the entire structure of one of the layers;

2, can easily use the new implementation to replace the original level of implementation;

3. Can reduce the dependence between layer and layer;

4, in favor of standardization;

5, facilitate the reuse of the logic of each layer.

6, the structure more clear

7, in the late maintenance, greatly reduced maintenance costs and maintenance time

Disadvantages

1, reduce the performance of the system. This is self-evident. Without a tiered structure, many businesses can access the database directly to get the data, and now they have to do it through the middle tier.

2. Sometimes cascade changes are caused. This kind of modification is especially reflected in the top-down direction. If you need to add a feature in the presentation layer to ensure that the design conforms to the layered structure, you may need to add code to the appropriate business logic layer and the data access layer.

3, increase the development cost.

The difference from MVC

Edit

MVC (Model model-View view-controller controllers) is an architectural pattern that you can use to create a distinction between a domain object and a UI presentation layer object.

The same architecture level, the same thing is that they all have a presentation layer, but they are different in the other two layers.

The concept of a controller is not defined in the three-tier architecture. This is the most different place. and MVC does not consider the logical access of the business as two layers, which is the main difference between a three-tier architecture or an MVC build program. Of course. The model is also mentioned in layer three, but the concept of model in the three-tier architecture is not the same as the concept of model in MVC, and the typical model layer in the "three layer" is made up of entity classes, while MVC is composed of business logic and access data.

Three-tier architecture (not MVC)