The difference and connection between VO, DTO, DO and BO in Java architecture (super detailed explanation)

---

---

foreword

This blogger will use CSDN to record the experience and knowledge he has personally gained and learned on the way to study software development. Interested friends can pay attention to the blogger! Perhaps a person can go fast alone, but a group of people can go farther!

1. Concept

In Java programming, the four terms VO, DTO, DO, and BO all represent different object types. The differences and connections between them are as follows:

1、VO (View Object)

VO (View Object), which is used to represent a view object that interacts with the front end, and its function is to encapsulate all the data of a specified page (or component). In fact, here VOonly includes the data that the front-end needs to display. For the data that the front-end does not need, such as the time of data creation and modification, in order to reduce the size of the transmitted data and protect the database structure from leakage, it should not be in the VOreflected in.

2、DTO(Data Transfer Object)

DTO(Data Transfer Object), used to represent a data transfer object, usually used for data transfer objects between DTOthe presentation layer ( Controller) and the service layer ( ). Similar to in concept , and generally the fields are basically the same. But there are some differences between and , this difference is mainly in the design concept, for example, the service needs to use may be different from .ServiceDTOVODTOVOAPIDTOVO

3、DO(Data Object)

DO(Data Object), the persistent object, which Daoforms a one-to-one mapping relationship with the data structure of the persistence layer ( ). If the persistence layer is a relational database, each field in the database table corresponds to POan attribute, usually entityan entity class.

4、BO（Business Object）

BO（Business Object）: Business objects, usually used in the business logic layer, represent the realization of business logic. BO is mainly responsible for the processing of business logic, including data verification, data processing, business logic processing, etc. BO can call multiple DOs and combine multiple DOs to form a complete business process.

2. Why does Vo exist?

In the project, I saw that others directly wrote DTO, wrote swagger comments, and returned directly to the front end. Then think about it, why it is not recommended to do this, instead of returning the DTO directly to the front end.

⭕From the perspective of the development process , the front-end and back-end will first use voand paramas the definition of the protocol for returning and passing parameters. Before defining the protocol, there is no actual business logic processing, so it will not exist dto.

⭕From the overall consideration of the project , if dtothe object is passed to the front end, then servicethe layer returns dto. serviceAll the methods of the layer are not necessarily publicmethods, and there are privatemethods. If privatethe methods also return dto, then some dtoare not provided to the front end. Some are for the front end, so it will be messy and there will be no isolation.

⭕In terms of field modification , servicelayer methods can be shared. serviceWhat is returned by one method may be used dtoby many methods. Even if not currently, it may be possible in the future . There will be many parameters, such as including the main table Information, sub-table information, but only a part of the information is passed to the front end, and the data seen by different requests to the front end is different, so it is shared and personalized . If it is directly provided to the front end, it will lead to coupling It is very large. Once the requirements of an interface change, modify , or add a field, the interface will directly return the newly added field to the front end, resulting in (interface output data redundant, and insecure). In the same way, if due to a certain requirement, the interface displayed to the front end says to delete a certain field, then because this field is referenced by many interfaces, once it is deleted, it will cause problems.controlllerdtovodtodtovodtodtodtodto

Therefore, in terms of the overall structure: vo must exist, and dto cannot be returned directly to the front end. High cohesion, low coupling. The general data transfer is that the front end transfers VO to the interface (Controller), the interface converts VO into DTO and transfers it to the service, and the service decomposes DTO into DO, calls the domain service for scheduling, and then reverses to VO or other return results, and transfers to the front desk.

3. Summary

In general, VO, DTO, DO, and BO are different objects in the layered architecture. Each object plays a different role in its own layer, and each has its own characteristics and uses. In actual development, these objects should be used flexibly according to business needs and architectural requirements, so that the coupling and complexity of the system can be reasonably controlled and reduced.