My Architecture Experience series-backend architecture-Design Level

Return to index http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html

 

Design Level:

 

• Layered Architecture

Layered Architecture is an important part in project design. It aims to separate responsibilities. The most classic three-tier architecture, from four to five, six layers, some people joke that the 18-tier hierarchy can be divided into different layers according to the needs of the project. The layer mentioned here is actually the logic layer. From the perspective of the physical layer, there are also layer-3 and layer-4 layered architectures. The reason why the three-layer architecture is so popular is that its hierarchy separates large concerns, and the layers are just right. The presentation layer, business logic layer, and data access layer, it processes user-oriented, logic-oriented, and database-oriented data access concerns respectively.

1. In a layered architecture, you also need to extract the models you need for each layer, for example, the view model of the presentation layer, the business model or domain model of the business logic layer, and the entity of the data access layer. Of course, if there is a service layer, There are contracts or data transmission objects at the service layer. One problem that arises is how to convert these entities or models. Of course, the simplest and most reliable method is handwriting.CodeAssign values. If there are more than 10 field attributes in the object, it will crash. Therefore, many mapper class libraries can be used to convert different models.
2. The clarity and readability of the system code are directly affected by the hierarchical score. Some people may ask, if I use a layer-3 structure, it is nothing more than the upper-layer invocation layer. If I have changed the database field, I have to change the layer-3 structure at the same time. Is that a lot of trouble? In fact, the reason for this is: first, your project is not big enough, or the logic is too simple. As a result, your code is called by the upper and lower levels. Second, even if you mix all the Code together, modifying the database field also requires modifying the SQL statement. Also, you need to modify the parameter validation rules to display this field on the interface, in fact, there is not much to change, but the code is mixed up, and it seems that there are not many changes. Third, modifying database fields does not happen frequently for a stable system. We often change the interface to change the logic, in this case, if there is a layer, we only need to modify the code of the corresponding layer. If each layer is separateProgramIf the set or sub-jar package is compiled, we only need to replace the component.
3. Although the three-tier architecture is simple, it is not so easy to implement the Separation Concept of the three-tier architecture. For example, if the operation determines that the field must be a number, should it be written at the presentation layer, business logic layer, or database layer? We need to make it clear that each layer is only responsible for its own responsibilities. We should not go beyond the authority, and we must do everything well. First, this judgment should be performed on each layer. The performance Layer script and code verification can fulfill the responsibilities of the performance layer, and the business logic layer cannot not be verified because the performance layer is verified, the business logic layer does not care about what the presentation layer has done. If the parameter does not conform to the type, It is proposed, similarly, the data access layer must ensure that the numeric type parameters are set to the correct type. Clearly understand what each layer needs to be responsible for, and clearly understand that each layer only cares about its own affairs, so that the correct code can be written in the correct position.

 

• High Cohesion and low coupling

High Cohesion and low coupling are a very important design concept. In fact, everyone knows this concept, but how can we implement it in code? I think we can grasp the following principles and keep them in mind:

1. Every method checks whether only one thing is done. If a piece of code is displayed on the interface again, there are SQL statements, or the employee's salary is being processed and the employee's attendance is being processed, it often means that this code has done too much and is not your own thing. It may be divided into two methods, or even two methods of different types.
2. Check whether only one task is performed for any type. This is a very important check. If a type does too many tasks, obviously, you have not clearly defined the responsibilities of the type (of course, this type is the exception for the facade type to be coordinated). check whether all the functions in the class comply with the class name, if a networkingadapter type contains code that processes XML, Is it inappropriate to use other inherited types to process XML, or to process different data in a policy-like mode?
3. Any piece of code checks whether it only appears in one place. This is also a very important check. We can often use this golden standard for restructuring. If a piece of code appears in multiple places, or it is a piece of code that is not relevant to the business, it can be solved by AOP, or there is a big problem, and the same business logic appears in multiple places, once there is a change to the business logic, the number of people knows to change two or more places, it is obvious that the Code should be extracted and encapsulated in one place.
4. Check whether any type depends on too many types. A type should not depend on too many types unless it is a facade type. If a type depends on too many types, it is strongly coupled with other types. You can consider using the facade mode to sort out the relationships between types and minimize the associations with too many types.
5. If a type is checked to see if it is dependent on the type, it also depends on itself. If this two-way dependency is generated, we recommend that you use a man-in-the-middle to process the dependencies between two types, instead of requiring mutual calls between the two types. Sometimes we can consider that type A writes the data to a place, and type B obtains the data from this intermediate point and then processes the data. Then, the result is stored in this intermediate point, type A then obtains the result from this intermediate point. In this case, a and B do not actually have a strong dependency. Everyone depends on the intermediate point to obtain the result. Even if B is replaced with C, as long as the output is similar, A does not need to be modified.

 

• Design Mode

All the design patterns are summed up by our predecessors after a large number of programming practices. Each pattern is applicable, and each pattern solves a problem, therefore, my suggestions for the design pattern are as follows:

1. You should understand every design pattern, and then you can naturally think of using the appropriate pattern at the right time.
2. Do not abuse the design pattern. A good design pattern can enhance the Code's high cohesion and low coupling, and make the code more scalable, however, misuse of design patterns may cause code performance problems and unnecessary coding.
3. As the design pattern for developing gof, you should be familiar with it, but it is not enough to read it. You can try to apply the design pattern in the future coding process. If a design pattern is useless, it will be written in the book, if it is used, it will be in your mind.

 

• Object-oriented

Many people are familiar with the three elements of object-oriented, but I personally think that it is necessary to fully understand the three elements of object-oriented. Process-based development is actually result-oriented, which is easier to understand. However, OO development is maintenance-oriented. The code developed through Ood is easier to expand and can support complex businesses. It may be difficult to extend a set of good oo code. Because every object has its own responsibilities, you need to understand the relationship between objects, once you get started, you will find it very nice. You can use a large number of types already implemented in the system. If you inherit and rewrite them to meet your own needs, you can also insert your own implementations into the original OO system through the Implementation interface, that is, the system can be transformed only by several lines of code. It is not difficult to get started with code transformation without Oo, because the code is straightforward, but once dozens of transformations are performed, the code will not be maintainable, because all the code is intertwined and there will be a lot of hard coding (the result-oriented code is characteristic that it can be changed from top to bottom in many places, and can achieve the same effect, once this is done, the original logic may be damaged and the code maintainability will be reduced ). My experience in learning Oo is:

1. Starting with the design pattern, the design pattern is a summary of OO. Learning the design pattern helps to understand the three concepts of OO.
2. You can read the code of an excellent framework or class library. An excellent open-source framework must be scalable. Therefore, its design is usually very oo.Source codeIt can improve the capability of Ood.
3. Multiple refactoring and multiple thoughts. Based on the problems mentioned above in High Cohesion and low coupling, you can find a way to refactor the code. You will find that many optimizations can only be implemented through oo, think about refactoring and then refactor to make progress.