The business logic layer plays a key role in the system architecture. It is located between the data access layer and the presentation layer, and plays a linking role in data exchange. Since the layer is a weakly coupled structure, the dependence between layers is downward. The bottom layer is "ignorant" to the upper layer. Changing the design of the upper layer has no impact on the bottom layer it calls.
If the idea of interface-oriented design is followed during layered design, then this downward dependence should also be a weak dependency. Therefore, without changing the interface definition, the ideal layered architecture should be a "drawer" architecture that supports extractability and replaceability. Because of this, the design of the business logic layer is particularly critical for an architecture that supports scalability because it plays two different roles.
For the data access layer, it is the caller; for the presentation layer, it is the callee. The relationship between dependence and dependence is entangled in the business logic layer. How to realize the decoupling of dependency relationships is a task left to designers in addition to implementing business logic.
Data layer
Data access layer: Sometimes also called the persistence layer, its function is mainly responsible for database access, and can access database systems, binary files, Text document or XML document.
To put it simply, it is to implement the operations of Select, Insert, Update, Delete on the data table. If you want to add ORM elements, it will include mapping between the object and the data table, as well as the persistence of the object entity.
Advantages and Disadvantages
Advantages
1. Developers can only focus on one layer of the entire structure;
2. It can easily replace the original layer implementation with a new one;
3. It can reduce the dependence between layers;
4. There are Conducive to standardization;
5. Conducive to the reuse of logic at each layer.
6. The structure is clearer
7. During later maintenance, the maintenance cost and time are greatly reduced
Disadvantages
1. Reduced system performance. This is self-evident. If a hierarchical structure is not adopted, many businesses can directly access the database to obtain the corresponding data, but now it must be done through the middle layer.
2. Sometimes it will lead to cascading modifications. This modification is particularly reflected in the top-down direction. If a function needs to be added to the presentation layer, in order to ensure that its design conforms to the hierarchical structure, it may be necessary to add corresponding code to the corresponding business logic layer and data access layer.
3. Increased development costs.
Rules
The three-tier structure program does not mean that the project is divided into three modules: DAL, BLL, and WebUI. It is called three-tier. The following questions are in your Inside the project:
1. There are only a few (or no) SQL statements or stored procedures calls in UILyer, and these statements are guaranteed not to modify the data?
2. If Can your project still provide all functions at the Interface/API level if UILyer is removed?
3. Can your DAL be transplanted to other projects with similar environments?
4. Can the three modules be run on different servers?
If not all answers are YES, then your project cannot be regarded as a three-tier program in the strict sense. Three The layer program has some rules that need to be agreed upon:
1. The most critical thing is that the UI layer can only be used as a shell and cannot contain any BizLogic processing procedures
2. The design should start from the BLL Starting from the starting point, not the UI. The BLL layer should implement all BizLogic on the API, in an object-oriented way
3. Whether the data layer is a simple SqlHelper, or with Mapping Classes should be system-independent to a certain degree of abstraction
4. Regardless of whether you use COM+(Enterprise Service) or Remoting, or remote object technologies such as WebService, regardless of whether they are actually deployed to different servers during deployment, at least such considerations must be made during design, and more Furthermore, you have to consider clustering multiple servers through load balancing
So when considering whether a project should apply a three-tier/multi-tier design, you must first consider whether it is really needed? In fact, most of them It is enough to open a WebApplication program, and there is no need to make it so complicated. The multi-layer structure is used to solve truly complex project requirements. The difference between
and MVC
MVC (Model-View-Controller) is a design pattern that we can use to create a distinction between domain objects and UI presentation layer objects.
It is also at the architectural level. The same thing is that they all have a presentation layer, but the difference lies in the other two layers.
The concept of Controller is not defined in the three-tier architecture. This is what I think is the most different. MVC does not regard business logical access as two layers. This is the main difference between using a three-tier architecture or MVC to build a program. Of course. Model is also mentioned in the three-tier architecture, but the concept of Model in the three-tier architecture is different from the concept of Model in MVC. The typical Model layer in the "three-tier" is composed of entity classes. In MVC, it is composed of business logic and access data.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
