Understanding of PO, VO, BO, POJO, DAO, DTO, TO in JAVA

Table of contents

1. Ali specification

1.1. Service/DAO layer method naming convention

1.2. Domain Model Naming Convention

1.3. Naming style

2. Simple class: including DO/DTO/BO/VO, etc.

3. Relationship with MVC three-tier architecture

4. Summary

4.1. Why divide these objects

4.2. When do you need to define so many O

4.3. How to convert between entity objects?

References


1. Ali specification

First, look at the relevant descriptions of POJO /DO/DTO/BO/VO in the Ali Development Manual .

1.1. Service/DAO layer method naming convention

1) The method of obtaining a single object is prefixed with get.
2) The method of obtaining multiple objects is prefixed with list.
3) The method of obtaining statistical values ​​is prefixed with count.
4) The insert method is prefixed with save (recommended) or insert.
5) The delete method is prefixed with remove (recommended) or delete.
6) The modified method is prefixed with update.

1.2. Domain Model Naming Convention

1) Data object: xxxDO, where xxx is the name of the data table.
2) Data transmission object: xxxDTO, where xxx is the name related to the business field.
3) Display object: xxxVO, where xxx is generally the name of the web page.
4) POJO is the collective name of DO/DTO/BO/VO, and it is forbidden to name it as xxxPOJO.
 
Notice:
The word for transmission: Transmission, so the data transmission object is referred to as DTO

1.3. Naming style

[Mandatory] Use the UpperCamelCase style for class names, except for the following cases: DO / BO / DTO / VO / AO / PO / UID, etc.
       Positive example: ForceCode / UserDO / HtmlDTO / XmlService / TcpUdpDeal / TaPromotion
       Negative example: forcecode / UserDo / HTMLDto / XMLService / TCPUDPDeal / TAPromotion

[Mandatory] When defining POJO classes such as DO/DTO/VO, do not set any attribute default value. (4) OOP protocol
[Mandatory] When defining POJO classes such as DO/DTO/VO, do not set any attribute default value.
       Counter-example: The default value of createTime of POJO class is new Date(), but this property does not put a specific value when data is extracted, and this field is updated when other fields are updated, resulting in the creation time being modified to the current time.

2. Simple class: including DO/DTO/BO/VO, etc.

DTO (Data Transfer Object) data transfer object
Data transfer for different applications
DAO (Data Access Object) data access object

        It is a data access interface, mainly to interact with the database. It is mainly used to encapsulate the access to the data. Note that it is the access to the data, not the access to the database.

DO(Data Object)

        Alibaba specifically refers to the POJO class that corresponds to the database table one-to-one.

DO (Domain Object) domain object
        Domain object DO is a tangible or intangible business entity abstracted from the real world. In data-related operations, when data exists in the database and is retrieved using DAO access, these data are generally defined into classes in a standardized manner, and this class is DO, which is used to receive entities corresponding to the database. It is an abstraction Data state, between database and business logic.

Generally, it is used to receive data when the business logic layer (Service) accesses the database (SQL).

xxxDO, xxx is the data table name

In addition: DO is conceptually the same as Entity, they are one thing in practical application. The slight difference is that DO is an Entity that has a certain mapping relationship with the database. Generally speaking, DO is a type of Entity.

The VO (View Object) view model
         is used to interact with the front end, accept the data returned by the front end, and return it to the front end for view display

xxxVO, xxx is generally the name of the web page.

AO (Application Object) Application Object
        AO is a relatively general concept, because it is too common and does not deliberately describe its details. Take a very simple chestnut: the control layer (Controller) queries one or more pieces of data in the business logic layer (Service), and the transportation of this data transmission process is completed by AO. In normal business logic, there are generally many types of data, such as integers, characters, collections, classes, etc., which we collectively call AO.

The abstract reuse object model between **Controller** and **Business Logic Layer (Service)** is sometimes very close to the presentation layer, and the degree of reuse is not high.

BO (Business Object) Business Object
        Business Object (Business Object, BO) is a component that retrieves and processes data. The main function is to encapsulate business logic as an object. This object can contain one or more other objects. Image description refers to the form and action of an object, and of course some forms and actions of other objects are also involved.

It is generally used in specific instances containing business function modules. For example, we wrote a series of instances such as a Controller, a Service, a DAO, and a tool class to achieve some functions. These series of instances are combined into a component. This component is BO.

POJO (Plain Ordinary Java Object) pure ordinary Java object
        POJO refers to DTO with only setter/getter/toString. In general, POJO includes DO, DTO, BO, and VO, which are essentially simple java objects. They are actually ordinary JavaBeans, which are abbreviations created to avoid confusion with EJB

PO (Persistent Object) persistent object
    
corresponds to the properties and fields of the database

Entity (a concept in the application domain) entity
        Entity (a concept in the application domain)
entity

        Eitity is an object that has not been persisted, it is a class, a class that abstracts from reality to code.

Model (concept entity model) Entity class and model
        Model are two concepts in computer programming: one is
the entity class in the three-tier architecture , and the other is the model in the MVC architecture.

3. Relationship with MVC three-tier architecture

        In the "three-tier architecture", for object-oriented programming, the data transferred by each layer is encapsulated into entity classes, which facilitates data transfer and improves readability.

        In the MVC (Model Model-View View-Controller Controller) pattern, Model represents the model, which is the processing of business processes/states and the formulation of business rules, accepting the data requested by the view, and returning the final processing results. View represents a view and is used to parse the data model brought by Model. The design of the business model can be said to be the most important core of MVC.

        The three-tier architecture in the usual sense is to divide the entire business application into: presentation layer, business logic layer, and data access layer . The purpose of distinguishing levels is the idea of ​​"high cohesion, low coupling".

Presentation layer (web): used to receive user submission requests and response processing.
Business logic layer (service) : business logic processing of data.
Data access layer (dao): The transactions done by this layer directly operate the database, for data addition, deletion, modification, update, search, etc.

insert image description here

4. Summary

PO persistent object: one-to-one correspondence with database attributes and fields

DO domain objects: business objects based on entities and events, when building complex systems, adopting domain-driven design ideas can reduce the complexity of development

DTO data transfer object: used for data transfer of different applications, distributed, name of microservice

VO value object: used to interact with the front end, accept the data returned by the front end, return it to the front end, and make a view display

BO business object: encapsulate multiple POs and process various businesses at the Service layer

4.1. Why divide these objects

Because in different businesses, the role of the same object is different. For example, adding a user requires a password, but viewing information can only return part of the information, and even sensitive information needs to be handled specially, although there are annotations that can help us solve these problems , However, the processing is not comprehensive, and it cannot be processed according to the situation. On the contrary, it increases the complexity of the business and
reduces the direct coupling of the business. When our requirements change, I change the content of the field without affecting other businesses. The normal execution of
the program allows programmers to know the name and understand the meaning. When we name the object, we must name it with XXXDO, xxxVO, so that other programmers also know how to deal with this information when maintaining our code.

4.2. When do you need to define so many O

Is it really necessary to define VO, BO, PO, DO, DTO in the project? In theory

If the project is relatively small, it is a simple MVC project, and it is a single-soldier operation, I do not recommend using VO, BO, PO, DO, DTO, just use POJO to be responsible for the transmission of each layer, because the "purpose" of this project ground" is done quickly.
And most of the time, we are continuous iterative team collaboration projects. At this time, we recommend using VO, BO, PO, DO, DTO, and a consensus must be reached within the team to form a standard specification.

4.3. How to convert between entity objects?

BeanUtils.copyProperties(srcVo,destDto);
mapper.map(srcVo,DestDto.class);

References

Refer to In-depth understanding of the concept of DAO

Concept POJO Xiaofengwanyuedan's blog

"Ali Java Development Manual Huangshan Edition"

Understanding the concept of vo, dto, bo, do, po Albertliuc's blog

Guess you like

Origin blog.csdn.net/qq_20957669/article/details/130588911