The interaction of the links and their isolation. Part 1

Original author: Chad Z. Hower aka Kudzu
  • Transfer
Logical links in n-link systems should 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, about 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 that we discussed in “ Where is our business logic, son? "(" Dude, where's my business logic? ").

Physical links

Consider how the physical links are arranged relative to each other:

In this example, a 3-link system is presented. All links can only interact with neighboring layers.

Direct access from the client link to the storage link is prohibited, as they are not neighbors. Most developers will not even try to make such a leap. However, in the article I will describe how developers without even noticing violate this rule in logical layers.

Layer links

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 exclusively a logical layer. Layers exist within a link, and, accordingly, links consist of layers.

Layers are not rigidly attached to links. In reality, as shown in the following two figures, the business layer can move between links, depending on the particular implementation. Not all layers are mobile, but many. The implementation depends on the network topology and other factors.

Layer of business logic in the storage link

Layer of business logic in the client link

Logical Limb

For demonstration, I will use three layers, despite the fact that n-link systems can contain more layers. Each layer should communicate only with the neighboring layer, and depend only on the neighboring layer.

If you place them on the links, we get a picture that matches one to one.

So we imagine logical layers; if only connections through interfaces are expected, the match will be complete. In the logical layers, we need to pay attention only to the connections to the interface, but also to the design of the interface, interconnections and other restrictions. All these are ghosts of logical layers that are not paid attention to or even not noticed.

This is a fairly common implementation. The presentation layer has no 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 demonstrated only the top level. However, each layer has its own additional sublayers.

If you add typical logical connections, you will notice a clear violation of the rule "access only to neighbors".

In some cases, the rule is not violated not only at the logical level, but physical contacts occur, jumping over neighbors.

Such systems are extremely fragile, difficult to upgrade, expand and debug. To work with any layer, the developer must be a "Fairytale developer." In the sense that he must know everything bad and good about the whole system.

If you remove the links and arrange the layers on the diagram differently, you can easily see what happened. Obviously, there was not just jumping the layers, but the creation of some kind of web.

Design Patterns

Design pattern from data storage layer

When using this template, the data storage layer is first designed, and then the presentation layer is attached to it. At the end of these works, a layer of business logic is attached to the data layer, because the presentation layer has already been designed based on the data layer. This leads to foreign restrictions in the presentation layer, and limits the ability to change data in the business logic layer. The data returned from the business logic layer is often limited to simple changes that can be performed using SQL queries or stored procedures.

This pattern 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 real data structure and has a non-intuitive interface.

Very often there is feedback of the presentation layer with the data layer. Feedback appears when some data cannot be received in a format acceptable in the presentation layer. Then the developer has to make changes to the data storage layer to improve the presentation layer, but such changes may be undesirable for the data storage layer. Such changes are alien, and if not for the limitations of the environment, they would not be required. Such changes often disrupt or simply interfere with the proper construction of the database, lead to unnecessary duplication of data and denormalization.

Design pattern from presentation layer

With this approach, the data storage layer is designed based on the presentation layer. An 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 the isolation approach, the presentation layer and the data storage layer are designed to be independent of each other and, often, in 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 data layer.

Because the presentation layer and the data layer are now completely independent, any of them can be changed and, if necessary, will entail changes in the business logic layer. Changes in either of two physically isolated layers do not directly affect the other layer. This allows us to quickly make structural changes in the presentation layer or in the data storage layer, and quickly respond to user needs, without full-scale changes or updates to the entire system.

Design from the data storage layerDesign from view layerIsolated Design
  • Well designed
  • Some unwanted trade-offs present
  • It’s hard to make changes because the presentation layer is rigidly attached to it
  • Poorly designed
  • Denormalized
  • Difficult to use with other systems
  • It’s hard to make changes because the presentation layer is rigidly attached to it
  • Can be well designed
  • It is used exclusively for data storage, and is deprived of the influence of the view
Business requirements
  • Often does not meet business requirements
  • Often meets business requirements.
  • Meets business requirements
  • It is generally scalable, but often requires major changes in the user interface to reflect changes in the data structure, or duplicate data
  • Has an inherent scaling problem.
  • Duplicate functionality is the norm
  • Just scale

I want to apologize to the public for breaking the article into two parts. But recently large texts have ceased to be accepted by Habré. If someone tells me how to deal with this misfortune: I will be grateful.

Also popular now: