1. The background
When it comes to application layering, most people think it’s not that simple: Controller, Service, Mapper. This may seem simple, but many people don’t actually divide their responsibilities. In many code, controllers do more logic than services, and services tend to be pass-through.
This is one of the things that a lot of people don’t notice when they’re developing code, because it works anyway, so it doesn’t matter where you put it. This often leads to the following code can not be reused, hierarchy disorder, the maintenance of the following code is very troublesome.
It’s true that layering is just a formality in the eyes of these people, that my predecessors wrote it that way, that other projects wrote it that way, so I wrote it that way.
However, in real team development, everyone’s habits are different, and the written code is bound to have its own label. Some people are used to controller writing a lot of business logic, while others are used to calling remote services between services, which leads to the completely different development code style of each person.
Subsequent others modify, a look, I am the person to write the code and my usual habit is completely different, the modified time is according to your previous habits change, still follow predecessors, it is a difficult choice, choose once there is deviation, your successors and maintain your code, I’m afraid I will swear.
So a good application layering requires the following:
- Facilitate subsequent code maintenance and extension.
- Layering needs to be accepted by the whole team
- Clear boundaries of responsibilities at each level
2. How to layer
2.1 Ali Specification
The hierarchy of constraints in Ali’s coding specification is as follows:
Open interface layer: Service methods can be directly encapsulated to expose RPC interface; HTTP interface encapsulated through the Web; Gateway security control, traffic control, etc.
Terminal display layer: The layer where the templates on each end render and perform the display. Currently, velocity rendering, JS rendering, JSP rendering, mobile terminal display, etc.
Web layer: it mainly forwards access control, verifies all kinds of basic parameters, or simply deals with services that do not reuse.
Service layer: The relatively specific business logic Service layer.
Manager layer: general business processing layer, which has the following characteristics :1. For the layer encapsulated by third-party platform, it preprocesses returned results and transforms abnormal information; 2. 2. The sinking of general capabilities of Service layer, such as cache scheme and general processing of middleware; 3. Interact with DAO layer and reuse multiple DAOs.
DAO layer: Data access layer, which interacts with MySQL, Oracle, and Hbase at the bottom.
The layers in Alibaba regulations are relatively clear and simple, but the description is too simple, and many students are still a little confused about the relationship between the service layer and the Manager layer, which leads to the existence of the Manager layer in many projects. How to implement layering in a specific business
2.2 Optimization of stratification
An ideal model has been summarized from our business development. It should be explained first that since our RPC framework uses thrift, it may have one more layer than other RPC frameworks such as Dubbo, and its function is similar to controller layer
1. Controller and TService at the top are the first layer in ali’s hierarchical specification: light business logic, parameter verification and exception exception. Usually the interface type can be easily changed, so the business logic must be light, or even do no concrete logic.
2.Service: the business layer has low reusability. It is recommended that each controller method should correspond to a Service instead of putting the business orchestration into controller.
If we do the orchestration at the Controller layer, and if we want to access thrift later, we will need to do the orchestration again, which will cause the code to be copied again each time we access the entry layer as shown in the following figure:
This amount of rework is bound to make our development less efficient, so we need to put the business orchestration logic into services:
3.Mannager: Reusable logic layer. The Mannager can be a single service, such as our cache, MQ, etc., or it can be a compound, which can be combined into a single Mannager when you need to call multiple mannagers, such as a logical join table query, etc. If it is httpMannager or rpcMannager you need to do some data conversion at this layer
DAO: Database access layer. The DAO is mainly responsible for “operating a table in the database and mapping it to a Java object”. The DAO should only allow its own Service to access the data, and other services must access the data through the corresponding Service.
3. Transformation of hierarchical domain model
The following domain model specifications are listed in the Alibaba coding specification:
- Data Object (DO) : Transfers Data source objects up through the DAO layer in one-to-one correspondence with the database table structure.
- Data Transfer Object (DTO) : a Data Transfer Object that is transmitted by the Service or Manager.
- BO: indicates a Business Object. An object that encapsulates the business logic output by the Service layer.
- AO (Application Object) : indicates an Application Object. The abstract reuse object model between Web layer and Service layer is very close to the display layer, and the reuse degree is not high.
- VO (View Object) : Display layer objects, usually transmitted by the Web to the template rendering engine layer.
- Query: Data Query object. Each layer receives Query requests from the upper layer. Note that query encapsulation with more than two parameters is prohibited by using the Map class for transmission.
Each layer basic their corresponding domain model, so it caused some people too pursuit of each layer is with your own domain model, which led to an object may appear three times 4 times even in a request, also can appear when return 3-4 times, this may be a full request – return object will appear many times. If this were true in development, there would be nothing else to write about and nothing to write about for one day.
So we have to come up with a compromise:
- Allow the Service/Manager to manipulate the data domain model at a level that would otherwise do business logic processing and data assembly.
- The domain model of the Controller/TService layer does not allow the DAO layer to be passed in, thus not meeting the responsibility division.
- Similarly, data from the DAO layer is not allowed to pass into Controller/TService.
4. To summarize
In general, business layering is important for code specification, which determines whether future code can be reused, whether responsibilities are clear, and whether boundaries are clear.
Of course, this kind of stratification actually varies from person to person, and everyone in the team has different habits of stratification, so it is difficult to weigh up a standard criterion. In general, as long as the duty logic is clear and the follow-up maintenance is easy, it is a good stratification.
Finally, if your team has better layering, or if there is anything wrong with the above description, please leave a comment.
From: juejin. Cn/post / 6844903636334542856
