The interaction of links and their isolation. Part 1
Logical links in n-tier systems must be designed so that they interact and are influenced only by neighboring links. This restriction is often violated, which negatively affects the system. In this article, I will explain why this usually happens, the consequences, and why you should pay great attention to the isolation of layers.
The article is devoted to the basics and is a detailed description of them. The following articles with detailed examples will be based on it. This article is based on the principles we discussed in “ Where is our business logic, son? "(" Dude, where's my business logic? ").
Consider how the physical links are relative to each other:
')
This example shows a 3-tier system. All links can interact only with adjacent layers.
Direct access from the client to the storage link is prohibited because they are not neighbors. Most developers will not even try to make such a leap. However, in the article I will describe how developers even without noticing break this rule in logical layers.
The terms tier and layer are often used interchangeably. When I use the term “link,” I mean the physical link. When I use a "layer", I mean an exclusively logical layer. Layers exist within the link, and, accordingly, the links are composed of layers.
Layers are not rigidly tied to the links. In reality, as shown in the following two figures, the business layer can move between links, depending on the specific implementation. Not all layers are mobile, but many. Implementation depends on network topology and other factors.
For the demonstration I will use three layers, despite the fact that n-stage systems can contain more layers. Each layer should communicate only with the adjacent layer, and depend only on the adjacent layer.
If we place them on the links, we get a picture that matches one to one.
So we imagine the logical layers; if only connections via interfaces are assumed, the match will be complete. In logical layers, we need to pay attention not only to the interface connections, but also to the interface design, interconnections and other restrictions. All of this - the ghosts of logical layers, which do not pay attention or do not even notice.
This is a fairly common implementation. The presentation layer does not have a physical connection with the storage layer, but both were developed depending on each other, and reality introduced limitations that required compromise solutions.
The situation becomes clearer if we place the layers so as to better see the connections between them. Instead of a transparent multilayer system, we get a typical cyclic system.
I showed only the top level. However, each layer has its own additional sublayers.
If you add typical logical connections, you can notice a clear violation of the “access only to neighbors” rule.
In some cases, it is not the rule that is broken not only at the logical level, but physical contacts also jump over the neighbors.
Such systems are extremely fragile, difficult to update, expand and debug. To work with any layer, the developer must be a "fairy tale developer." In the sense that he must know all the bad and good about the whole system.
If you remove the links, and arrange the layers in a different way on the diagram, you can easily see what happened. Obviously, it was not just skipping layers, but the creation of some kind of web.
When using this template, the data storage layer is designed first, and then the presentation layer is attached to it. Upon completion of these works, a layer of business logic is attached to the data layer, since The presentation layer has already been designed based on the data layer. This leads to alien constraints in the presentation layer, and limits the possibilities for changing data in the business logic layer. Data returned from a business logic layer is often limited to simple changes that can be made using SQL queries or stored procedures.
This template is very typical, because It is very similar to the traditional client-server approach in development and to systems designed around existing databases. Due to the fact that the presentation layer is designed based on the data storage layer, the presentation layer often displays the actual data structure and does not have an intuitive interface.
Very often the feedback of the presentation layer with the data layer is encountered. Feedback appears when some data cannot be received in a format acceptable in the presentation layer. The developer then has to make changes to the data storage layer to improve the presentation layer, but such changes may not be desirable for the data storage layer. Such changes are alien, and if it were not for the limitations of the environment, they would not be required. Such changes often violate or simply interfere with the proper construction of the database, lead to unnecessary data duplication and denormalization.
With this approach, the data storage layer is designed based on the presentation layer. The implementation of a business logic layer usually consists of simple SQL queries and practically does not transform or isolate. Databases are poorly designed and have performance problems because they were originally made to conveniently provide data to the presentation layer, without taking into account normalization and other requirements typical of databases.
When using an isolation-based approach, the presentation layer and the data storage layer are designed to be independent of each other and often parallel. After designing these two layers, the architecture of the business logic layer is developed, and it is his task to provide all the necessary transformations without affecting the presentation layer or the data layer.
Because the presentation layer and the data layer are now completely independent, any of them can be changed, and if necessary entails changes in the business logic layer. Changes in either of the two physically isolated layers does not directly affect the other layer. This allows us to quickly make structural changes to the presentation layer or to the data storage layer, and to respond quickly to the needs of users, without full-scale changes or updates to the entire system.
I want to apologize to the public for breaking the article into two parts. But lately, large texts have ceased to be accepted by Habrom. If someone tells you how to deal with this scourge: I will be grateful.
a continuation
The article is devoted to the basics and is a detailed description of them. The following articles with detailed examples will be based on it. This article is based on the principles we discussed in “ Where is our business logic, son? "(" Dude, where's my business logic? ").
Physical links
Consider how the physical links are relative to each other:
')
This example shows a 3-tier system. All links can interact only with adjacent layers.
Direct access from the client to the storage link is prohibited because they are not neighbors. Most developers will not even try to make such a leap. However, in the article I will describe how developers even without noticing break this rule in logical layers.
Links layers
The terms tier and layer are often used interchangeably. When I use the term “link,” I mean the physical link. When I use a "layer", I mean an exclusively logical layer. Layers exist within the link, and, accordingly, the links are composed of layers.
Layers are not rigidly tied to the links. In reality, as shown in the following two figures, the business layer can move between links, depending on the specific implementation. Not all layers are mobile, but many. Implementation depends on network topology and other factors.
Business Logic Layer in the Storage Link
Business Logic Layer in Client Link
Boolean Limb
For the demonstration I will use three layers, despite the fact that n-stage systems can contain more layers. Each layer should communicate only with the adjacent layer, and depend only on the adjacent layer.
If we place them on the links, we get a picture that matches one to one.
So we imagine the logical layers; if only connections via interfaces are assumed, the match will be complete. In logical layers, we need to pay attention not only to the interface connections, but also to the interface design, interconnections and other restrictions. All of this - the ghosts of logical layers, which do not pay attention or do not even notice.
This is a fairly common implementation. The presentation layer does not have a physical connection with the storage layer, but both were developed depending on each other, and reality introduced limitations that required compromise solutions.
The situation becomes clearer if we place the layers so as to better see the connections between them. Instead of a transparent multilayer system, we get a typical cyclic system.
I showed only the top level. However, each layer has its own additional sublayers.
If you add typical logical connections, you can notice a clear violation of the “access only to neighbors” rule.
In some cases, it is not the rule that is broken not only at the logical level, but physical contacts also jump over the neighbors.
Such systems are extremely fragile, difficult to update, expand and debug. To work with any layer, the developer must be a "fairy tale developer." In the sense that he must know all the bad and good about the whole system.
If you remove the links, and arrange the layers in a different way on the diagram, you can easily see what happened. Obviously, it was not just skipping layers, but the creation of some kind of web.
Design Patterns
Design Pattern from Storage Layer
When using this template, the data storage layer is designed first, and then the presentation layer is attached to it. Upon completion of these works, a layer of business logic is attached to the data layer, since The presentation layer has already been designed based on the data layer. This leads to alien constraints in the presentation layer, and limits the possibilities for changing data in the business logic layer. Data returned from a business logic layer is often limited to simple changes that can be made using SQL queries or stored procedures.
This template is very typical, because It is very similar to the traditional client-server approach in development and to systems designed around existing databases. Due to the fact that the presentation layer is designed based on the data storage layer, the presentation layer often displays the actual data structure and does not have an intuitive interface.
Very often the feedback of the presentation layer with the data layer is encountered. Feedback appears when some data cannot be received in a format acceptable in the presentation layer. The developer then has to make changes to the data storage layer to improve the presentation layer, but such changes may not be desirable for the data storage layer. Such changes are alien, and if it were not for the limitations of the environment, they would not be required. Such changes often violate or simply interfere with the proper construction of the database, lead to unnecessary data duplication and denormalization.
Design pattern from the presentation layer
With this approach, the data storage layer is designed based on the presentation layer. The implementation of a business logic layer usually consists of simple SQL queries and practically does not transform or isolate. Databases are poorly designed and have performance problems because they were originally made to conveniently provide data to the presentation layer, without taking into account normalization and other requirements typical of databases.
Isolated Design Template
When using an isolation-based approach, the presentation layer and the data storage layer are designed to be independent of each other and often parallel. After designing these two layers, the architecture of the business logic layer is developed, and it is his task to provide all the necessary transformations without affecting the presentation layer or the data layer.
Because the presentation layer and the data layer are now completely independent, any of them can be changed, and if necessary entails changes in the business logic layer. Changes in either of the two physically isolated layers does not directly affect the other layer. This allows us to quickly make structural changes to the presentation layer or to the data storage layer, and to respond quickly to the needs of users, without full-scale changes or updates to the entire system.
| Designing from the storage layer | Designing from the presentation layer | Isolated design | |
| Database |
|
|
|
| Business requirements |
|
|
|
| Scalability |
|
|
|
I want to apologize to the public for breaking the article into two parts. But lately, large texts have ceased to be accepted by Habrom. If someone tells you how to deal with this scourge: I will be grateful.
a continuation
Source: https://habr.com/ru/post/107563/
All Articles