Please discuss layering, not L3

After discussing the language, discussing the training, and discussing the layers, it seems that these topics will never be discussed. The discussion is always beneficial, but if there is a problem with the proposition itself, the side effects may be greater than the benefits.

Layer 3 = presentation layer + business logic layer + data access layer?

Is it true that all systems must be divided into three layers? Is it true that all three layers of systems must be divided into three layers? If I write an application that does not require data storage, if I write an application with no interfaceProgramWhat about database?

Why is Layer 3 A Layer 3? Because all discussions are based on "Small and Medium B/S or c/s application systems", because such systems are currently the most common and most common. However, we should not only look at this field, but should put it in a longer-term. layering is a common concept and cannot be confined to the "three" layer, it cannot be limited to "UI + BL + Dal ". Layer-3 is only a special case of hierarchy. The combination of UI + BL + dal is also a special case of the layer-3 system. Understanding the special case does not mean understanding the hierarchy; however, when we understand the hierarchy, We can naturally understand this special case. Therefore, do not discuss layer-3. directly discuss layers. This will reduce misunderstandings and arguments. For example, those who say that the layer-3 (ui + BL + DAL) is not good will not deny the layer. They can still be divided into two or more layers, rather than rejecting the layer; the discussion will also be limited to whether the three layers are useful, whether a layer should be changed or the number of layers should be changed, when should it be divided into three layers, and when should it be divided into two layers.

Let's talk about the advantages and disadvantages of layering. Nothing is perfect. It can only solve some specific problems. It is not its fault that cannot solve all the problems. It is definitely your fault to use it to solve the problems it is not good at solving.

the reason I like layering is that layering can encapsulate underlying operations so that you can only consider the following layers when working on any layer, you don't need to consider the details of all the lower layers, or even the total number of layers. This is an abstract mechanism. This is a set of names. You will use "getallusers" instead of "select * from users order by ID" to think about the problem, you will use "get shopping list" instead of "get a list that is full of the products I bought and their prices ", if there is no layering, you may want to consider how an electron sets a binary bit in the memory to "1" when writing Code ". I have met a system that is very small and contains thousands of lines of code. It uses VB to access a. ini configuration file, a database, and an execl template. Its main function is to obtain some data from the database according to the configuration information of. ini and put it in a cell of the template. The code is short but difficult to understand. Every time it executes an operation, it calls almost the same 3-5 lines of code to read. INI file. The only difference between these codes is the key value to be read and the type of the returned result (forced type conversion ). It is easy to see that you only need to extract a function. Yes, just extracting a function greatly increases the degree of clarity of the code and reduces repeated code. This function is actually a "data access layer. the access details of the INI file are encapsulated, and no code that uses it needs to know the implementation details. You only need to know that you can call this "getvaluefromconfig (key)" to get what you want. In this way, you can get rid of the details of every consideration of how to access the configuration file and focus on the higher-level logic. By the way, many people think that the role of the "data access layer" is to replace the database. In fact, this situation does not happen frequently in programs outside the framework. ABSTRACT Data Access in applications is a more common motivation.

Of course, as mentioned above, layering also has its own problem: first, cascade modification. A typical example is to add a field to a website, and you need to modify each layer. Another problem is performance. The more layers, the more performance is affected. However, these shortcomings are not the reason you do not need to layer. Cascade modification may be caused by the absence of a defined interface between layers, or the change of requirements. If it is a normal requirement change, the number of cascade modifications is limited, and it does not cover the benefits of layering. If cascade modifications are too frequent, it may be that the demand is too unstable or the architecture design is faulty. As for performance problems, the speed of the computer is getting faster and faster, and the bottleneck of the system is usually in disk I/O or network transmission. The CPU and memory consumption caused by layering is not the main problem in most systems, therefore, unless it is a program with limited resources and high performance requirements, this is generally not a problem.

So how many layers are appropriate? What are the responsibilities of each layer?

The number of layers depends on the complexity and characteristics of the application. If your system itself is not complex and many layers are divided, there must be no logic in some layers, the troubles brought by these simple layers will be greater than the benefits. If there are too few layers, the concepts of different levels of abstraction will be mixed in one layer, this makes your thinking always jump between the top and bottom layers, resulting in confusion of logic code. There is no specification for hierarchy. Any hierarchy system must be tested in practice. Layer 3 is a good start, but it is not the end. When you think that Layer 3 is inappropriate, change it, believe in your intuition, rather than some so-called "authority" that "three layers of good, must use, two layers are evil, SP is evil ......". Maybe one day you will agree that Layer 3 is better than Layer 2, but when you still don't know why Layer 3 is better, you can use Layer 3 (or something else you think is better ), it is much better to misuse three layers than to be ignorant, misunderstand the three layers, and finally stay away from the three layers.