When participating in the research and development of other projects today, I have some views on the layering of the java background of their projects:
First, the concept of layered design using service domain dao layers is encouraged.
Secondly, the understanding of the role of several layers:
First: the dao layer operates a single table, which does not involve complex logic, mainly the addition, deletion, modification and query operations of the table, and the data is queried completely according to the requirements of the domain.
Second: the domain layer considers business logic, such as filter conditions, release or return, and data processing, to prepare for calling the dao layer, a domain can call one or a group of related dao layers
Third: the service layer calls one or a group of domain layers, mainly to display the interfaces that need to be opened. Not all interfaces of the domain layer need to be reflected in the service layer, and only a few interfaces may be opened in the service layer. In addition, The main interface needs to expand the accepted parameters as much as possible, that is to say, it can accommodate the access (Object) of various types of parameters, and then it needs to be converted at the service layer for use by the domain layer.
The correct design should be that a domain activity will aggregate one or a group of DAOs to complete a domain activity. A service may contain activities in two fields, such as a transfer business, corresponding to activities in two fields. The amounts of the two accounts are changed separately, and a set of domain activities need to be operated, and each activity needs to operate many tables (calling multiple DAOs).
Using the interface method can achieve loose coupling between systems:
General definitions: IUserService UserService IUserDomain UserDomain IUserDao UserSqlDao UserHbaseDao
Using the interface can have different implementation classes, no need to change the code, you can change the different implementation classes through configuration