The difference between vo, dto, po

pojo: the entity class corresponding to the data table

Pojo is also written as po, entity, domain: represents a specific entity in the system, such as users, orders, products, etc. Usually it is mapped to the corresponding entity of the database table, including the attributes and related methods of the entity.

Personal understanding: It means what fields are in the data table, and the entity entity class has corresponding fields. When the attribute name of the entity class is inconsistent with the field name of the database table, we will use the attribute of this class to correspond to the field of the table one by one.

Example: user entity class corresponds to database table

@Entity
@Table("user")
public class User {
    
    
    //用户
    private String username;
    //年龄
    private String age;
    //地址
    private String addr;
}

dto: Receive data from the front end

DTO (Data Transfer Object): Used to transfer data between different application layers. Usually designed to reduce network or system overhead and improve performance, including those classes and objects that are transferred between application layers.

Personal understanding: dto is to define the message sent by the receiving front end, and these messages are placed in a DTO entity class, which may combine fields of multiple entity classes.

example:

  • UserDTO
public class UserDTO extends User {
    
    
    //第几页
    private Integer page;
    //每页多少条
    private Integer size;
}
  • The controller receives parameters
@RestController
public class UserContrller {
    
    

    @PostMapping("/findUser")
    public void findPageByUser(@RequestBody UserDTO userDTO){
    
    

    }
}

vo: data returned to the front end

VO (Value Object): Also known as Data Transfer Object (DTO), it is used to display data in the presentation layer. It is usually a new object formed by selectively combining some attributes in the entity object representing the data. The purpose is to A specific data structure that satisfies the data requirements of the presentation layer.

Personal understanding: It is to encapsulate the data that needs to be returned to the front-end display into vo. vo may be several fields of a table, or it may be the fields of multiple tables put together, and then returned through vo.

example:

  • vo entity
public class UserVO {
    
    
    private String username;
    private String addr;
}
  • back to front
    @PostMapping("/findUser")
    public UserVO findPageByUser(@RequestBody UserDTO userDTO){
    
    
        UserVO userVO = new UserVO();
        userVO.setUsername("张三");
        userVO.setAddr("北京");
    return userVO;
    }

bo: the entity class when called by the controller layer and the service layer

BO (Business Object): Located in the business layer of the application, it encapsulates the business logic and process, and is separated from the data storage and presentation layer. It provides management and operation methods for entities, and is often used to deal with complex business scenarios involving multiple entities.

Personal understanding: It is an entity that can increase or decrease data when the business logic layer and the controller layer call each other and process business logic.

AO: More complex entity classes

AO (Composite Object): Similar to BO, but it represents a group of related business objects, often used in scenarios such as batch operations and complex associated queries.

The latter two are rarely used, so I won’t introduce them more.

The code requirements of each company are different. Some use xxxParam for receiving request parameters and xxxRep for returning data. You can create them according to your needs, as long as you can understand them.

Finish! ! ! ! !
hy:9


		年轻人,去结婚吧,如果你有个美丽的妻子,你会生活得幸福;如果不是,你会和我一样变成个哲学家。---苏格拉底

Guess you like

Origin blog.csdn.net/weixin_49107940/article/details/131014375