Layer-3 architecture: entity layer and appearance

Yesterday, the seven-phase senior brothers and sisters explained the three layers and three paradigms to us.

About Layer 3:

The understanding of Layer 3 has been deepening step by step. no matter whether the understanding is right or wrong, at least three layers can be said to others, but further, no.

After listening to yesterday's explanation, I found that the most difficult thing to understand is not layer B or layer D, not the U layer, but the entity layer.

The bll layer is responsible for the business logic, that is, the business-related information is placed on the B layer. The U layer is the performance layer. The interaction between the supervisor and the user, user input, and display to the user are all tasks at the U layer. Layer D is the data access layer, and the supervisor deals with the database.

I read an article about Layer 3 a few days ago. In his article, I wrote a series of articles about verifying whether it is empty and putting it on layer B. The benevolent and wise are wise. Some people think that as long as judgment is involved, it should be placed on layer B, and some people think that this is related to the interface, so it should be placed on the u layer.

What are the advantages of B? That is, the U layer code can be less. When the interface layer is changed, the new U layer only needs to pass the value. In this way, the B layer will become very bloated. I feel that B is the most troublesome reason.

I personally think the most difficult thing to understand is the entity layer, which is "jumping out of the three boundaries, not in the five lines ". It does not belong to any layer of Layer 3, but each layer of Layer 3 is associated with it. The initial understanding is how many tables have at least one entity class. The attribute of each object class is the table field.

Slowly, I think there is a problem in dividing object classes in this way, because when multiple tables are involved, the object classes cannot be returned, so the object classes are created based on views. In a word, Hong Ge is even more awake: in fact, you can write all the fields in nine tables into one entity class.

Although everyone will not do this, this idea tells us that the entity class is not a provision, and it can be transformed completely according to your needs. How can we use it more in line with the object-oriented architecture, there are not so many rules. That's why he "jumped out of the three realms, not in the five rows.

In the face of the problem that fields need to be known when datatable, U or B is returned, a method with parameters of the datatable type is written at the Entity layer, so the responsibility for understanding fields is handed over to the entity layer, in this way, the decoupling between the U, B, and D layers is achieved.

Some people added their appearances when drawing pictures. Yesterday, our sister-in-law asked us whether we thought about how these fine-grained packages correspond to coarse-grained packages. This is not too difficult, so we won't say it. The following figure further explains my understanding of the appearance (the previous article describes my understanding of the appearance-a summary of the IDC charging system ):

The example here is an on-premise instance. First, let's take a look at the logic diagram:

In this scheme, the B layer is written based on the u layer, but the return statement is similar in the B layer, and there is almost no corresponding judgment, all these work is done at the appearance layer. The appearance is used for decoupling. In fact, this does not achieve the goal of decoupling. At the meeting yesterday, Yong Ge said that the best way to decouple is the interface, and the appearance here does not provide an interface, it is similar to a class at Layer B. When the appearance is used, it seems that the B layer is overhead, just like the appearance layer directly calling the data access layer.

The following figure shows the logical appearance:

(Other associations are removed in layer B.) because the check card number exists and whether it is being used repeatedly on the server, the function is abstracted in layer B for reuse. Here, the corresponding logic exists in layer B. layer B does what it should do and does not give it to the appearance, therefore, although fine-grained packages can correspond to coarse-grained packages, they are different.

The following describes the meaning of the appearance. If there is no appearance, it will be the following figure:

In this way, the U layer needs to know that there are too many B layers, and the coupling is too high. Our system is simple. There are two main functions in a form on the machine. But if there are too many features on the form, isn't the ing between the U layer and the B layer messy? Then the appearance is triggered.

In the Application appearance, we cannot place what layer B should do in the appearance, just like writing your d-Layer Code to passing parameters and so on. It is worse than execute of CMD, then you will return a CMD and let him execute at Layer B (which may be inappropriate, but the truth is the same ).

There is a long way to understand the design mode. The design mode used in the charging system of the data center is far-fetched in addition to the abstract factory and reflection, which is conducive to changing the database.

I was writing two articles together, so everyone must be tired of reading them. Thank you again for reading them.

Next, let's talk about the design model used by the data center charging system.