Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to correctly layer the relevant knowledge in the Java project, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this article on how to layer correctly in the Java project. Let's take a look at it.

Background

When it comes to application layering, most people will think that this is not very simple, just Controller,Service,Mapper three layers. It looks simple, in fact, many people do not divide their responsibilities, in a lot of code, Controller does more logic than Service, Service is often regarded as transparent transmission, this is actually a lot of people do not pay attention to the development of code, anyway, the function can also be used, as for where it does not matter. This often results in the following code can not be reused, the hierarchical relationship is confused, and the maintenance of the subsequent code is very troublesome.

Indeed, in the eyes of these people, layering is just a form, the older generation's code is written in this way, and other project code is written in this way, then I will follow suit.

But in real team development, everyone's habits are different, the code must be written with their own tags, some people are used to Controller writing a lot of business logic, some people are used to calling remote services between Service.

As a result, everyone's development code style is completely different. when others modify it later, the code I rely on this person to write is completely different from my usual habit, whether to change it according to my previous habit or to follow my predecessors.

This is another difficult choice. If there is a deviation in the choice and your descendants maintain your code, I am afraid you will scold others.

So a good application layering requires the following:

Convenient for subsequent code to maintain and expand

The effect of layering needs to be accepted by the whole team.

The responsibility boundaries of each layer are clear.

How to carry out hierarchical Ali specification

The layering of constraints in Ali's coding specification is shown below:

① open interface layer: it can directly encapsulate Service method and expose it to RPC interface; encapsulate it into http interface through Web; carry out gateway security control, flow control, etc.

② terminal display layer: a layer in which templates at each end render and perform display. At present, it is mainly velocity rendering, JS rendering, JSP rendering, mobile display and so on.

③ Web layer: it mainly forwards access control, verifies all kinds of basic parameters, or simply handles services that are not reused.

④ Service layer: a relatively specific business logic service layer.

⑤ Manager layer: general business processing layer.

It has the following characteristics:

For the layer encapsulated by the third-party platform, the preprocessing returns the result and converts the abnormal information.

The sinking of the general capabilities of the Service layer, such as cache scheme, general processing of middleware.

Interact with the DAO layer and reuse multiple DAO combinations.

⑥ DAO layer: data access layer, which interacts with the underlying MySQL, Oracle, and Hbase.

The layering in the Alibaba specification is relatively clear and simple, but the description is still too simple, and the relationship between the Service layer and the Manager layer is still a little unclear, which leads to the fact that there is no Manager layer in many projects.

Here's how to achieve layering in a specific business.

Optimize layering

From our business development summed up a more ideal model, here to explain that because our RPC framework uses Thrift may be more than some other RPC frameworks such as Dubbo will have one more layer, the effect is similar to the controller layer.

The top layer Controller and TService are the first layer of our Ali hierarchical specification: light business logic, parameter verification, exception background.

Usually this kind of interface can easily change the interface type, so the business logic must be light, or even do no specific logic.

① Service: business layer, low reusability. It is recommended that every Controller method should correspond to a Service. Do not put business choreography in Controller. Why?

If we put the business orchestration at the Controller layer, if we want to access Thrift in the future, we need to do the business orchestration again, which will result in a new copy of the code for each entry layer we access.

As shown in the following figure:

Such a large amount of repetitive work is bound to lead to a decline in our development efficiency, so we need to put all the business orchestration logic into Service:

② Mannager: reusable logic layer. The Mannager here can be a single service, such as our Cache,MQ, etc., or it can be composite.

When you need to call multiple Mannager, this can be combined into one Mannager, such as logical join table query and so on. If it is httpMannager or rpcMannager, you need to do some data conversion at this layer.

③ DAO: database access layer. Mainly responsible for "manipulating a table in the database and mapping to a Java object", DAO should only allow its own Service access, and other Service must access my data through the corresponding Service.

Transformation of hierarchical Domain Model

The following domain model specifications are listed in the Alibaba coding protocol:

DO (Data Object): one-to-one correspondence with the database table structure, transferring data source objects up through the DAO layer.

DTO (Data Transfer Object): a data transfer object, an object that Service or Manager transfers outward.

BO (Business Object): business object. An object that encapsulates business logic output by the Service layer.

AO (Application Object): application object. The abstract reuse object model between Web layer and Service layer is very close to the presentation layer, and the degree of reuse is not high.

VO (View Object): display layer objects, usually objects that Web transfers to the template rendering engine layer.

Query: data query object, and each layer receives the query request from the upper layer. Note that query encapsulation with more than 2 parameters is prohibited from using the Map class for transmission.

Hierarchical domain model Controller/TServiceVO/DTOService/ManagerAO/BODAODO

Each layer basically has its own corresponding domain model, which leads some people to pursue each layer with their own domain model.

As a result, an object may have 3 or even 4 transformations in one request, and 3-4 conversions will also occur when returned, so it is possible to have a complete request-return will have many object transformations.

If it really follows this way in development, I'm afraid don't write anything else, just write this repetitive and useless logic in one day.

So we have to adopt a compromise:

Allow Service/Manager to manipulate the data domain model, and at this level, what you are supposed to do is business logic processing and data assembly.

The domain model of the Controller/TService layer does not allow the introduction of the DAO layer, which does not conform to the division of responsibilities.

Similarly, data from the DAO layer is not allowed to be passed into Controller/TService.

This is the end of the article on "how to layer correctly in the Java project". Thank you for reading! I believe you all have a certain understanding of "how to layer correctly in the Java project". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.