Excellent code is how layered?
background
Speaking layered application, most people will agree that this is not a very simple thing to controller, service, mapper three. Looks simple, in fact, a lot of people do not open their segregation of duties, in a lot of code, controller logic to do more than the service, service is often as a pass-through, and this is actually a lot of people are not aware of the development code of the place, anyway function can also be used, which does not matter as to put chant. This often causes behind the code can not be reused, hierarchy confusion, follow-up maintenance of the code is very troublesome.
In the eyes of these people really just a form of stratification, predecessors of the code written so other project code written so, so then I have to follow to write. But in the real team in the development of each person's habits are different, write code that is bound with his own label, some people used to write a lot of business logic controller, some people used to call a remote service between service, so everyone has led to the development of the code completely different style, follow others modified, look, I rely on this person to write code and completely different from my usual habit, modify the time in the end in his own previous habits change, or follow the predecessors to go, this is a difficult choice, selection bias once, your younger and maintain your code, probably would curse.
Stratified good points
1. facilitate subsequent code maintenance extended ;
2. The need for a layered effect for the whole team accepted;
3. The various layers of responsibility clear boundary .
Ali specification
The basic hierarchy
Open Interface Layer : Service packaging method of directly exposed to RPC interface; http encapsulated into a Web interface; a gateway for security control and flow control.
Terminal display layers : a template layer exhibits render and execute the respective ends. The main current is velocity rendering, JS rendering, JSP rendering, display and other mobile terminal.
Web layer : mainly for access control forwarding, all kinds of basic parameters check, business or simple treatment no longer used.
Service layer : a relatively specific business logic services layer.
Layer Manager : General business process layer, which has the following characteristics: 1 layer of the third-party platform package, and return the results pre-conversion abnormality information; generic capability to sink 2 Service layer, such as caching scheme, generic middleware. processing;.. 3 DAO layer interacts with the combination of multiplexing a plurality of DAO.
DAO layer : data access layer, data interaction with the underlying MySQL, Oracle, Hbase.
Hierarchical domain model conversion
The DO (the Data Object) : one correspondence with the database table structure, by DAO layer uplinked data source object.
The DTO (the Data Transfer Object) : data transfer object, Service Manager or outward transfer object.
BO (Business Object) : business objects. Encapsulate business logic layer output by the Service object.
AO (the Application Object) : application object. In the abstract object model multiplexing layer between the Web and Service layer, very close to the presentation layer, reusability is not high.
VO (View Object) : Object display layer, typically a Web rendering engine to the transmission layer template object.
Query : query object data, the upper layers receiving a query request. Note that more than two parameter query package, prohibit the use of the Map class transmitted.
Small Conclusions
Stratified statute of Alibaba relatively clear and simple and clear, but the description was still too simple, and the service layer and layer manager could not tell many students still somewhat the relationship between, has led to many projects do not have layers Manager presence.
Hierarchical model conversion: Each layer corresponds to the domain model are basically their own, thus leading to some people over the pursuit of each layer with its own domain model, thus leading to an object occur three times or even four conversions in one request, when the return of the same will occur 3-4 times the conversion, so it is possible to request a full - will be returned many times object conversion. Very wasteful.
Optimization
The basic hierarchy
Explain: Because our framework of choice is rpc thrift may for example dubbo will be more than some of the other rpc layer framework, similar to the role and controller layer.
The top controller and TService is our first layer specification Ali layered inside: light business logic, parameter validation, anomaly reveal all the details. Usually this type of interface the interface can be easily replaced, so the business logic must be light, not even specific logic.
Service : the business layer, low reusability, a controller is recommended every method had to correspond to a service, do not do business in the choreography on the controller, and why? If we do business orchestration layer on the controller, then, if in the future we want to access thrift, here again we need to do in a business arrangement, this will lead us to access an entry for each layer This code had to re-copy .
Mannager : reusable logic level. Mannager here can be a single service, such as our cache, mq and so on, of course, can be compounded when you need to call multiple Mannager, and this can be combined into a Mannager, such as query table even logical . If httpMannager or rpcMannager need at this level to do some data conversion
DAO : database access layer. Responsible for "a particular table operation of the database, mapped to a java object", dao should only be allowed to access their own Service, other Service to access my data must pass through the corresponding Service.
Conversion hierarchical domain model (compromise)
1、允许Service/Manager可以操作数据领域模型，对于这个层级来说，本来自己做的工作也是做的是业务逻辑处理和数据组装。
2、Controller/TService层的领域模型不允许传入DAO层，这样就不符合职责划分了。
3、同理，不允许DAO层的数据传入到Controller/TService。
总结
总的来说业务分层对于代码规范是比较重要，决定着以后的代码是否可复用，是否职责清晰，边界清晰。
当然这种分层其实见仁见智, 团队中的所有人的分层习惯也不同，所以很难权衡出一个标准的准则，总的来说只要满足职责逻辑清晰，后续维护容易，就是好的分层。