NET platform (many friends call it "three-tier architecture"), seems to be a long-lasting topic. Often see many friends to analyze, discuss, debate and even attack. After reading a lot of this article, I think a lot of friends in the understanding of the hierarchical structure there are two relatively large bias:
1. There is no understanding of the connotation of stratification from an essential point of view, but merely an understanding of its appearance.
2. The understanding of layered architecture is too narrow, but only a few concepts, but not deep enough.
Many friends say "stratification" will be called "Dal", "BLL", "presentation layer" and other concepts, but "dal" inside there are "Data Source schema", "Object-relational behavioral mode", " Object-relational Structural Mode ", and in each of these areas there are many specific models, such as" Data Source schema "and" Table Data Gateway "," Row Data Gateway "," Acitive Record "and so on. Besides "BLL", we all know that "BLL" is "business logic layer", but what is "business logic"? "BLL" can also be built as "Transaction Script", "Domain model", "Table Module" three modes, what is the meaning of each? In addition, the hierarchy is not only the "Data access Layer" + "business Logic Layer" + "presentation layer" This kind of division, such as "service Layer", "persistence layer", "Application control layer" concept friends are really familiar with it.
Cause this phenomenon, I think a large part of the reason is because most. NET platform developers (including me) understand that the layered architecture began with Microsoft's PetShop. Because PetShop is the official demo, so is the numerous. NET developers as the Bible, even became. NET platform, the standard scenario for tiered architectures. I have seen many friends in my blog left "layered architecture or petshop the most classic", "want to learn layering or see PetShop bar", "You this is to learn with PetShop" such a message. Friends too revered PetShop, but ignored the fact: it is just a demo. It is also unscientific to say that even if it is a practical project, the way to define an abstract concept through a specific project is not.
For example, a person does not know what "cow" is what, so consult a dairy farm administrator, the administrator moved out of a cow, told him: "This is the cow." From then on, if someone asked him what "cow" is, he will tell others "cow" is a large size, clumsy, docile character, the body has black and white plaque pattern, there is a good big Mimi, can be milked for people to drink. One day, he heard that there was a bull fight in Spain, he was shocked: "How can This!" The cow is so docile, how can it be used to fight! And cows are used for milking and drinking! ”
What mistake did the man make in the story? He equated the abstract concept of "specific cow" and "cow". He thinks that cows are "bulky, clumsy, docile, with black and white plaque patterns, and a good big Mimi that can be milked for people to drink." But the world there are cattle, buffalo, yak, bullfighting, beef cattle and other cattle. He failed to make "blinders" by "imagining the essence" to form an abstract concept.
In fact, many friends understand the layered structure is one-sided or biased, because the story with this person made the same mistake.
Originally, we do not know what is "layered architecture", so Microsoft gave us a petshop, said: "Look!" This is. NET platform under a tiered architecture. "So we" suddenly ":" Oh! This is the layered architecture Ah! ”。 In this way, we equate a "layered architecture" with an abstract concept that has great connotation and denotation, and a specific demo., which has become the story of the person-we say layered structure must be called DAL, the BLL, we do the project according to the PETSHOP way structure ...
We are indeed "poisoned" by PetShop. But it's not Microsoft's fault, it's not PetShop's fault, as in the story, we can't blame the dairy farm administrator or the cow. Wrong in our own!
when Microsoft gives us petshop, we should be aware in our minds that this is a demo of a layered architecture. Instead of understanding "this is the layered architecture." We should delve into, think, and grasp the nature of layered architecture, but we don't.Rather than
being "poisoned" by petshop, we have been poisoned by ourselves and by our own bad habits of study. We only look at the appearance, or only look at a representation, and then risk the hierarchical structure of the coffin of the verdict. And not through the imagination to see the essence. So, we also made the mistake of "blinders".
The above error, the author also once committed! So, in the following, I would like to share with my friends I am in the process of self-reflection, realize some of the experience, I hope to help more friends out of the "blinders" as soon as possible.
insight into the nature of layering
We can discuss how hierarchies can be discussed, and the pros and cons of layering can be discussed with no value ... But before all this discussion, let's get one thing straight: what is the nature of layering? Or: How does layering come about? If this question is not clear, then our other discussions are like "building a plateau above the sands", and the incisive rhetoric, if not a solid foundation, is untenable.
To understand the nature of stratification, we have to talk about division of labor. Division of Labor can be said to be the largest improvement in labour productivity, the benefits of the initial division of labor are embodied in the "comparative advantage", because of their respective roles, each person can engage in their best work, coupled with the labor of simple labor to improve the proficiency and reduce the loss of labor, resulting in a significant increase in labour productivity. However, with the development of society, we find that some special forms of division of labor can not only improve productivity, but also some other benefits! To understand these benefits, let's give a practical example.
Today is manger, a mother wants to buy a cream cake for her daughter as a gift. We know that cakes need flour, eggs, milk, and so on, and it takes a whole bunch of complicated processing and packaging processes, but the mother doesn't need to care about that, she just goes to the nearest supermarket and buys it directly. There are no chicken farms, no dairy farms, no wheat farmers, and baking cakes for workers. This simple "buy a cake" scene is about to be represented.
Figure 1, the division of the cake production Figure 1 shows about how a cake arrives in the customer's hand. Can be seen that the production of cakes is not a single labor, the need for a lot of division of labor, if viewed from the bottom up, the main division of labor includes: basic material information on the cultivation of production, raw materials processing, cake processing, commercial sales. Not all division of labor is like this, the division of labor shown, there are some characteristics, summarized below.
1. The lower layer does not know the existence of the upper layer. Dairy cows, for example, produce milk, do not need to know what to do with milk, may be bought by a cream factory to make butter, may be bought by ice-cream factories to make ice cream, may be bought to do toffee, in short, it does its own duty-the production of milk, and the upper layer of it is ignorant. In the same way, the cream factory produces cream, which does not have to know whether the cream is taken to make a cake or mocha coffee.
2. Each layer only knows its next layer (except for the last layer, since the last layer does not have the next layer) and does not know the other lower layers. For example, a cake factory needs to know how to extract flour, cream, and eggs from a flour mill, a cream factory and an egg factory, without having to worry about how the flour is coming and how the cream comes from these problems.
It can be said that the division of labor in line with the above two points is the thought source of layered architecture. Here's a little more formal.The
so-called layered thought is such a division of labor: it organizes the system according to different responsibilities into an orderly level. In addition to the top level, each layer provides only a number of services for its adjacent upper layer, but does not know the existence of the upper layer, except for the lowest level, each layer only calls its services near the lower tier.
Therefore, the so-called "layered thinking", but a special form of division of labor. The layered idea in computer software architecture is the special case of using this idea in software development, and the way of "DAL+BLL+PL" used by PetShop is simply the special case of the special case that applies this idea to software development. For example, if a system's business is simple, just adding and removing changes, then the BLL has no effect, "DAL+PL" the way can be done well, which is also a good layered architecture. Again, if a system of business is very complex, need to normalize, and then do the operation, then do the collation, then "dal+ normalization layer + COMPUTE layer + finishing layer +PL" This five-layer architecture is also very reasonable AH. It is also normal to use facade mode to add a "facade Service Layer" between the BLL and PL if the interface exposed by the BLL of a system is too cumbersome. Furthermore, if a system does not require data access functions, such as a calculator program, we just want to separate the representation and the Business (computing function), then there is no dal, "BLL+PL" is reasonable. Therefore, the structure of the layered thinking, the essence is "the system according to different responsibilities organized into an orderly level ..." this paragraph describes, rather than simply "dividing the system into DAL+BLL+PL", not "by petshop way of architecture."
Below, excerpt a section of Fowler's definition of layering in Patterns of Enterprise application Architecture:
When
thinking of a system in terms of layers, you imagine the principal subsystem in the software arranged in some for M of layer Cake,where each layer rests on lower layer. In this scheme the higher layer uses various services defined by lower layer,but lower layer is unaware of the higher Laye R. Furthemore, each layer usally hides it lower layers from the layers above.
--martin Fowler, "Patterns of Enterprise application Architecture", P17
The general translation is as follows:
when we say that a system is layered, you can think of the software as a layer of cake, where each layer is placed on its next layer. Higher tiers use services defined and provided by many lower tiers, but the lower layers are unaware of higher levels. In addition, each layer hides a lower layer on top of it.
--Martin Fowler, "Enterprise Application Architecture Model", P17
However, there is one thing to declare: although "DAL+BLL+PL" is not equivalent to a hierarchical schema, it is only an instance. But at the same time we have to be clear that this approach is so popular that Microsoft's official example is structured because many systems, especially large and medium-sized MIS systems, should give priority to this architectural approach. In this section, the author absolutely does not criticize the "DAL+BLL+PL", on the contrary, when the development of the system, this approach can be a priority, and then according to the characteristics of the system can be improved. The author emphasizes in this section: "DAL+BLL+PL" can not be regarded as the essence of layered architecture, but also can not be equated with the concept of "layered architecture".
analysis of the pros and cons of layered architecture
On the basis of understanding the nature of layered architecture, we can safely and boldly analyze the pros and cons of layered architectures. Cut the crap, we'll go straight to the chase.
The advantages of a layered architecture are as follows:
1. Isolate the developer's concerns. Since a layer invokes only the services provided by its next layer, as long as the API of this layer and the next layer of API definition are complete, developers can develop a layer as a focus on the ideas, patterns, and techniques used in this layer, which is equivalent to introducing the productivity improvement advantage of division of labor into software development. Another example of buying a cake, as a supermarket, as long as the lower API (how to get cake from the Cake factory) and this layer needs to implement the API (to sell the cake to customers), you can develop their own business model is a strategic plan, without concern about how to grow wheat, how to grind flour, how to make butter, how to make cakes. In this way, the supermarket only needs to carry on the commercial operation, but does not need to carry on the industry operation, so specificity, must raise the business level.
2. Non-destructive replacement. Imagine that if a dairy farm went bankrupt, would the cream factory go bankrupt? Of course not, it can quickly change a dairy farm, because each dairy farm can achieve the "provide milk" service. If, for example, one day the country has a policy requiring all cream factories to import raw materials from a qualified dairy farm, it happens that the cooperative milk suppliers of a cream factory fail to pass the review, so long as a review of the cooperation is done. And all the parts of the cream factory are not moving, because different dairy farms can provide the "supply of milk" service. And if the cream factory own cattle to produce milk, once encountered this policy, you have to go to the relevant departments to review, adjust the corresponding business process, reaching. The same thing in the procedure, the most commonly heard may be the migration database.
3. Reduce the dependencies between systems. Or the cake that example, if one day the Cake factory internal change machine, or business process adjustment, ask the customer to care? Obviously not, because the customer only calls the service provided by the supermarket. And the supermarket hides all the following industry details for customers. If every customer buys the same commodity, it is not exhausting to understand the series of details of the product from raw material production to molding to sales. In the change program, just as the presentation layer calls the service of the business layer, how many layers are there in the business layer? How are all the data coming? How to save it? Is it real or fabricated? Does not need to be understood, which greatly reduces the dependencies between the various responsibilities of the system.
4. Reuse. For example, you can go to this supermarket to buy things, I can also go to this supermarket to buy things. Cake Factory can be extracted from the flour mill flour, steamed bread factory can also. In this way, the same layer can provide services for the different upper layers and achieve the purpose of reuse. Specific to the program, for example, the Meteorological Bureau produced a "Service Layer" for providing weather forecast information. So Sina, Sohu These websites can use this service layer to provide the service, the production of Weather preview page, QQ can also use this service to add weather forecast on its chat tool, you do a software need to use the weather forecast function, also can call meteorological station "Service Layer".
Say the pros, and then talk about the drawbacks of layered architecture:
1. Cascade modification issues. This problem is not a good metaphor in reality, but in the process I believe a lot of friends understand. For example, a personnel management system that originally looked at people information can only be paged out, and now, you need to add a feature: In the pagination and also can be divided into departments. For example, you can view the top 50 people in the sales department so that all layers need to be modified for this feature.
2. Performance issues. Originally straightforward operation, now to layer to pass, bound to cause a decline in performance. As in the example of buying a cake. When customers enjoy the convenience of division of labor, they also have to bear the price of cakes due to the distribution of different layers of departments, which is due to the increase of cost, such as transportation, coordination and management costs of different layers of departments.
Looking at the above analysis, the layered architecture has pros and cons. It is certain that there are pros and cons to anything in the world, so it is unwise and unscientific to put "layered architecture in the sky" and "beat him" in both ways. To deal with the layered structure, our attitude should be to clarify its essence and pros and cons, and then make rational analysis and choice according to the specific situation.
From the above analysis, it can be seen that layered architecture can reduce the cost of changes in the layer, and is very sensitive to changes in the API. As mentioned in the Cascade modification of "at the same time the division of the Division" of the new requirements, is the changes to the API. The changes to the API are deadly for layered architectures and are very difficult to modify. So, a simple rule of thumb is:If there is a
high likelihood of frequent changes (or even full-layer replacements) within your system layer, and the likelihood of a small API change, use tiering, and if the API is likely to change frequently, use a layered architecture with caution.
In the
back.
In fact, I would like to say that the main content is the previous one. But there are some words, I want to nag with you.
This article, is not a technical article, so I do not mention technical details, but just to help you clarify the misunderstanding of the stratification. Recently, we have seen a lot of discussion on layered architecture (or three-tier architecture), which is mostly criticized, and some even think that layering is a useless junk thing. I think, the people who produce this kind of thought, basically pass through the following stage: Heard stratification, rough study stratification, imitate use stratification, use very uncomfortable, come out criticize.
In fact, any technology is objective, there is no error, wrong in person, is not the right use of people, or do not use the right place. Just as we cannot criticize the blade is not suitable for splits, nor can we criticize hatchet for shaving. A technology want to play the power, the key to the correct use, and to use correctly, we need to have a deep foundation, we need to study hard, diligent thinking. It is not a matter of overnight, but a long-lasting perseverance. We should strive to be a diligent, good at grasping the essence of the people, rather than a knife to chop wood, with hatchet shave, and then scold the blade and hatchet are garbage people.
Layered thinking has never been the first in the software architecture, we use the network every day to follow the OSI Seven layer protocol, network structure design is a model of rational application of layered ideas. In addition, layered thinking is common in many other engineering fields. So, instead of layering as a unique capability of computer people and even software developers, the technology for layering applications to software architectures is immature, and there are many things to do.
Do you really understand the layered architecture?
