What is Layer 3?

Recently I saw an article on the anti-three layer, and my hands are also itchy. I will sacrifice some time to discuss this old topic.

1. What is Layer 3?

Many people love to confuse the three-layer architecture with MVC, but we can consider their differences from the simplest perspective:

In the design pattern, there is usually such a chapter, the MVC design pattern, and I have never seen any book that has written a three-tier architecture design pattern.

Regression layer-3 is generally divided into two categories:

A. Physical Layer-3 Architecture

B. logical layer-3 Architecture

Now let's talk one by one to see if the third layer is going to go away.

2. Three-tier logical architecture

The three-tier logic architecture is conceptually easy, including the user interface layer, business logic layer, and data access layer. Each layer has its own proprietary responsibilities.

The layer-3 architecture is the core of all enterprise-level architectures. The layer-7 architecture in petshop, or the layer-5 architecture in general, is centered on the layer-3 architecture. Here we can say that n = 3.

Full-time display at the user interface layer to deal with users directly.

The business logic layer is used for complex business processing.

The data access layer is used to interact with the database for regular addition, deletion, modification, and query operations.

These are simple. Click here.

3. Physical Layer-3 Architecture

The physical layer-3 architecture is based on the logical layer-3 architecture. Without the logical layer-3 architecture, there is no way to deploy the physical layer-3 architecture.

What is a physical three-tier architecture?

In simple terms, each layer is made into one component, such as the business logic component, Business Entity component, and data access component.

The trouble is to build a distributed system. For example, deploy the business logic layer and data access on different servers.

4. Review stored procedures

As a sqlas, stored procedure has its own advantages and disadvantages, just like every language.

There are only three methods to deal with databases:

A. Write SQL statements in program logic, including SQL String concatenation, which is the most common

B. Use the ORM framework in the data access layer. In the. NET project, the main types are LINQ to SQL and nhib.pdf. (In fact, the two are not commonly used in actual projects)

C. Use stored procedures

Let's analyze their advantages and disadvantages:

In program logic, writing SQL statements is difficult to process complex business logic, difficult matching of quotation marks, complicated String concatenation, and efficiency loss during String concatenation.

The ORM framework is a good method. I don't report any doubt about this. However, the slightly poor Syntax of LINQ to SQL makes it easy for regular programmers to switch back and forth between C # And LINQ. Without talking about nhib.pdf, this is a non-mainstream framework for most Chinese companies, and its integration with vs is not very satisfactory.

Therefore, when processing complex logic, such as complex transaction processing, the stored procedure is almost the only method.

However, stored procedures share their fatal weakness, that is, their portability is poor,

A. When our project changes the database, we need to completely copy the stored procedure to another database, and then consider their compatibility issues.

B. When we modify the data layer access code, what we need to do is not the application server code, but the database code, which is a little painful.

5. Advantages of layer-3

Some people now question the Layer 3 and let the Layer 3 go away. The problem is not the Layer 3. He used three layers by mistake. A good knife should be used on the blade. Otherwise, I am afraid it will only be self-defeating.

So what are the advantages of Layer 3?

A. As mentioned above, the logical layer 3 is the prerequisite for the Physical Layer 3.

B. layer-3 enables each member to have their own concerns during team development and facilitates the division of labor among the group members.

C. Reuse the data access layer and business logic layer

D. Multi-language collaboration (for example, VB is used for the data access layer and C # is used for the business logic layer, which is rare)

E. It must be easy to maintain programs, but I personally think this is not obvious. As the brother said, If you modify a field, you need to modify it on all three layers.

6. Three layers are not three layers

Whether it is Layer 3 or not is a problem that has always plagued many people.

Like every design pattern, these are a double-edged sword. If you use them well, it will make you easy, but if you use them wrong, it will be counterproductive.

Whether it is Layer 3. You need to view the entire project, explore potential changes in advance, and then think about the benefits of using Layer 3 for this project.

If you don't think of it, do not go to Layer 3.

The common layer-3 scenarios are as follows:

A. product companies need to mask the underlying details, so they need to encapsulate a lot of access and business logic. At this time, there must be three layers.

B. The project is very large. It requires the cooperation of multiple members to make a member focus on both the top-layer business logic, the appearance of the page, and the efficiency of data access, which is unrealistic.

C. A huge project requires distributed application logic.

7. layer-3 extension

In all my articles, I emphasize the importance of thinking. I do not like to be restricted by my predecessors, and I do not like to trust the ideas in the book unless I have confirmed them. The same is true for this article.

In my opinion, the three layers are an idea. There is no need to say that this is the three layers, so it is not the three layers. This will make knowledge too dead.

I still remember the definition of Ajax by a foreign master: Ajax is a technology that can improve user experience.

In fact, I personally think the same is true for three layers: three layers can be called to adapt to changes, reuse, and facilitate the programmer's architecture.

8. Extended layer-3 Classification

A. Simplified Version:

When the business logic is simple, the business logic layer is simplified, so the structure is formed:

. Aspx is the user interface layer. aspx. CS is the business logic layer. CS is a separate data access layer.

B. Some changes

Generally, companies have their own data handler classes, just like sqlhelper in petshop. We can also name this layer separately, but this is a conceptual issue.

C. Separate business logic and business pragmatism

For many projects, the business logic processing is relatively complex. It is simple. For example, on the login interface, when a password is transferred to the database, an encryption process is required, we can encapsulate this process into the business logic layer. In addition, for some complex process processing, we can also go to the business logic layer.

Business entities are not mentioned, which is very common.

D. No business entity

In many office OA projects, data is often non-physical, because users can dynamically construct database table fields based on their own choices. Therefore, there is no need for business entities to exist.

E. extreme simplification

In many small projects, the business process is simple, the data processing is easy, and there is no complicated operation or team collaboration, so we do not need to layer. At this time, the layering only increases the coding volume and maintenance workload. So what is this situation?

I have mentioned this concept before. As long as our project can adapt to changes, be reusable, and facilitate the development of programmers, I will call it three layers. So, in fact, we can barely call him a "three-tier" approach.

9. Summary

Three layers are not three layers, and three layers are difficult to choose.

In my opinion, the best way to adapt to the changing architecture is.