Layer-3 Architecture

The three-tier architecture has a history of ten years. Although I did the application of the three-tier architecture at the time of my graduation, I did not really understand the problems that need to be solved by the three-tier architecture, it's just blind obedience.

 

People now know what a three-tier architecture is, nothing more than the user interface (UI), Business Logic (Business Logic) and Data layer (Data ). Both the UI and Data are good to say that Data is generally not a database (of course, it may also be a file system or other Data services, of course, DBMS must be the most), and the UI also understands, the user interface is always ready for use. Currently, it is basically a graphical interface, which is nothing more than a window, page, or report. The key is to put something in the business logic, which is often the most controversial part. Many people complain that the layer-3 architecture adds the complexity of the interface. Adding a layer conversion in the middle may cause performance problems. Therefore, we are often confused about the advantages of the layer-3 architecture?

 

Most people understand the business logic layer as a group of objects. They encapsulate all database operations. The user interface layer only calls the objects in the business logic layer for work, the methods for creating and calling objects are much simpler than SQL statements. On the other hand, you can only access the database through the business logic layer and perform security checks at the business logic layer, data Integrity assurance. It sounds good. In addition, it is said that the three-tier architecture facilitates division of labor, allowing the database-savvy dude to develop business logic-layer objects, and the UI-based dude's development interface, or you can quickly customize features for users. It seems perfect, so let's use this architecture.

You can do this, and the problem comes. There are several situations that are most common:

I) how to process the query results.
Query results usually return a large set of data, such as the result set of 1000 rows. The business logic layer queries the database to obtain a result set of 1000 rows of records, which should be unambiguous, but what if it is returned to the user interface? Is it packaged into an object, generating 1000 objects, and then returning the collection of these 1000 objects; or is it directly returning the queried result set?
If you re-package the returned object set, people with a little conscience will be a little scared, but creating 1000 objects and then assigning values to 1000 object attributes will obviously bring a lot of overhead, in addition, this kind of query occurs frequently. In the common "tree-list" application mode, a query is executed for each selection of Tree nodes, so frequent object creation and destruction will inevitably produce a lot of memory fragments, which is also a place that affects performance.
If the result set is returned directly, isn't it possible for the user interface to focus on the structure of the database or even the field name? What are the advantages of multiple middle layers at this time?

Ii) when the demand changes, there are more changes.
If there are still people imagining that the demand can be fixed before development (not to mention software outsourcing, that is code, not development), then he is not suitable for development and can switch. Changes in demand are permanent and remain unchanged only in the beautiful vision of people.
Once the demand changes, for example, a feature is added to the business object, you will find that a field is required in our database and an attribute needs to be added to the Business Object. An input box may be added to the user interface. Slow down. Aren't we saying that the layer-3 architecture is loosely coupled? Why should we change it together. Perhaps a clever designer can use the database extension field and object extension data method to apply such changes to the business logic layer and database layer. But what should I do when a business object is added or the relationship between the business object changes? You need to know that users are always more ignorant than you think, and that users will never be able to obey your architecture, even though you think the architecture is perfect.
My God, now, when there is a change, I need to modify three places. Instead, I only need to modify two places for the two-layer structure. Isn't that a problem for yourself.

I believe that only these two points can shake the confidence of many people. If not, we need to recall the benefits of the business logic layer:

A) database installation operations to separate the business logic from user operations. However, DBMS usually has Stored procedures (SP). I can put the business logic in SP. Isn't it also separated from user operations.

B) Provide business methods in the form of objects to simplify interface calls. This advantage seems to be still there, but it is only to wrap it into an object for convenient calling. In fact, deploying the Business Object and UI on a physical node can also achieve this effect, why am I launching an App Server?

C) enable developers to gain strengths and focus on the areas they are good. It's impossible for a team of dozens of people to be so meticulous. Based on the recruitment experience of the author, even if the three-tier architecture is divided, the work is not distributed by module. A man is working from the ground up.

Since there is a shortage of benefits, can we say that the three-tier architecture is "useless? I have also been confused about this issue.

 

However, the software industry, after all, is not an entertainment circle. There are hypes and more pragmatic people. Moreover, over the past few decades, the field of software has concentrated so many smart people around the world. Computer science itself is a subject closely related to practical applications. Everyone is an engineer and has been engaged for ten years, it is clear that it is of practical value and you need to know how many technologies have been abandoned over the years. Since it is not a problem of L3 architecture, it should be something we understand. The reason why we cannot understand the fundamental advantages of L3 architecture is that the scale of the applications we build is too small to reach that Level. When we want to select a three-tier architecture, please first ask ourselves: is the concurrent access volume of our system so high that we have to use Load Balance to solve the problem? Whether there are multiple data nodes, it is necessary to apply distributed transactions to ensure the effectiveness of data access; or is it possible that we have to divide multiple data nodes to store a large amount of data?

The purpose of hierarchy is to isolate the upstream of a party, so that when the downstream of a party changes, its upstream does not need to change accordingly. This change is not just a functional change, but a change in performance or application mode. For example, migrating from a LAN to the Internet originally met 1000 users and now needs to meet 100,000 users. This is actually the Scalability of the system. The three-tier architecture is designed to solve the Scalability problem. As for providing object-based packaging for business logic, the old man who used this three-tier architecture as an advantage repeatedly stirred up is simply a mistaken person, at least the author was mistaken in the past.

Why do we need the middle layer, because the data layer may change. The system may start to use Access and upgrade to SQL Server as the business volume increases. A table can record a type of data (such as transaction data ), now you need to split the table into multiple tables (by year or month, or vertical split of the master and slave tables). A data node can store all the data and needs to be deployed to multiple nodes. At this time, you only need to modify the intermediate layer object to meet the changes at the data layer, and the user interface layer does not need any changes. The system is growing, but the user experience is consistent.

In such an architecture, the data layer needs to be able to be split, or even support multi-node (DBMS usually does not support load balancing), or its own load balancing data services; the business logic layer (Middle Layer) must support load balancing, distributed transactions, and other advanced applications. The user interface layer, that is, the front-end service, must also support load balancing, to adapt to the concurrent access of tens of thousands or even hundreds of thousands of users in the future. The system is scalable. As for whether the business logic layer is object-oriented, let's do it by yourself. This is only because the design method has little to do with the architecture.

 

In a word, only in a highly scalable environment can the three-tier architecture reflect its own value. If one application server and one Database Server can cover all our applications, there will be no more than three-tier architecture, casual play, multi-layer analysis does not bring us too many benefits, but increases the complexity of the system.