I don’t know that many classes are found in their own system with BO, VO, DTO, DO classes, these simple data storage classes, what is the role?

I understand that there are two functions:

  • Generally, larger systems are designed in layers. The bottom layer is the data storage layer, database, and the top layer is the application/view layer that provides external interface calls. Each layer has associated data objects, so it needs to be differentiated accordingly.

  • Make class semantics more explicit and make it easy to know what a class means.

define

First, let’s take a look at the definition of Alibaba’s development statute:

Pojos (Plain Ordinary Java Object) : In this specification, POJOs refer to simple classes that only have setter/getter/toString, including DO/DTO/BO/VO, etc.

Specification of hierarchical domain model:

  • Data Object (DO) : Transfers Data source objects up through the DAO layer in one-to-one correspondence with the database table structure.
  • Data Transfer Object (DTO) : a Data Transfer Object that is transmitted by the Service or Manager.
  • BO: indicates a Business Object. An object that encapsulates business logic that can be output by the Service layer.
  • Query: Data Query object. Each layer receives Query requests from the upper layer. Additional rules: [mandatory] Encapsulate queries with more than 2 parameters. Do not use the Map class for transmission.
  • VO (View Object) : Display layer objects, usually transmitted by the Web to the template rendering engine layer.

— Alibaba Java Development Protocol

Detailed definitions of each word:

DAO: Data Acess Object (DAO) : Data Acess Object (DAO)

  • Encapsulating access to the database, regular add, delete, change and query (CRUD operations) are implemented through DAO.

PO/DO: Persistent Object/Data Object, Persistent Object/Data Object.

  1. A PO/DO data is a record of a database table.

  2. When Hibernate was used in the past, PO was used a lot, but now it is generally preferred to use DO, which depends on the specifications of each company.

  3. PO/DO is just an object of data and does not contain any operations. For example, StudentDAO is used to add, delete, change, or query a student table.

DTO: Data Transfer Object

  1. In distributed system, data can be transmitted between systems through DTO.
  2. Dtos can also transfer data within an application, between the core layer and the application layer. Dtos are simple data transmission without processing business logic.
  3. For example, if a database table has 10 fields, the fields ID (unique ID), version(version number), and GMT_CREATE (record creation time) DO not need to be provided externally. Therefore, DTO can only take meaningful service fields. DO is a one-to-one mapping with database records. But dtos only need to define the required fields according to the business needs.

BO: Business Object

BO encapsulates business logic as an object. This object can contain one or more other objects.

  1. BO is a very important concept in the domain model. BO is the smallest business unit.

  2. BO contains data objects (PO/DO) and operations on data.

VO: View Object, display layer Object

Data objects displayed on the corresponding page (Web page/MOBILE H5/Native view).

  1. For example, the DTO format is yyyyMMddHHmmss, but the VO format is yyyyMMddHHmmss.

practice

With all these concepts in mind, let’s look at the actual operation, first naming:

1) Data object: xxxDO, XXX is the name of the data table. 2) Data transfer object: xxxDTO, XXX is the name related to the business field. 3) Display object: xxxVO, XXX is generally the name of the web page. 4) POJO is a general name of DO/DTO/BO/VO. It is forbidden to name it xxxPOJO

Take the student archives management system as an example, we now need to do a student archives management background system, according to the above definition, we can define some of the following objects:

As shown below:

DB layer here should be called storage layer, here only DB, HBase, Redis, generally refers to the storage of data.

In the case of the Student table, the DB layer is responsible for storage.

  1. The DAO layer provides the interface of query, delete and write.

  2. DO is the DAO object, StudentDO, sometimes you skip DO, you write Student;

  3. The service layer or core layer does business logic processing, such as querying the interface, calling the DAO layer to obtain Student information according to the Student id, and then doing a data clipping, only fetching business fields, such as version number, self-increment ID, database record creation time and other non-business fields, obtaining a StudentDTO. Then, the ProfileDTO related to student profiles is queried and assembled into ProfileBO, which serves as the profile domain model.

  4. The business layer takes the BO from the Service layer, transforms the BO into a VO view object, and provides it to the front end for display.

When I was an intern after graduation from university, I wrote a code that the business layer directly called the DAO layer. I thought it was too tedious to go through the service layer and the core layer, and the fields were almost the same. However, I was guided by the Team Leader later.

He told me that both VO and DO may change with requirements. The principle of software design is to reduce coupling, which is strong coupling after all. When DO changes, VO does not need to be modified due to the existence of BO, and VO modification also does not need to modify DO data model. VO (view) and DO (data model) can change with the requirements. The principle of software design is to reduce coupling. After all, this design is strong coupling (binding view and data directly). VO changes also DO not require changes to the DO data model.