Database concepts: DO, DTO

The graduation project has come to an end. This time, the graduation project was carried out completely in accordance with the software engineering process. I have a lot of feelings. I will not write a summary for now. I will summarize some technical issues that occurred during the process. First, I would like to talk about several concepts of software design entities. .

In fact, there are four concepts in total: VO, DTO, DO, PO. According to my own understanding, I only talk about DTO and DO. However, explanations of four concepts are posted below:

(1) Concept explanation

VO (View Object): View object, used for the display layer, its function is to display a specified page (or component) encapsulates all data.

DTO (Data Transfer Object): Data transfer object. This concept comes from the design pattern of J2EE. The original purpose is to provide coarse-grained data entities for EJB distributed applications to reduce the number of distributed calls. , thereby improving the performance of distributed calls and reducing network load, but here, I generally refer to the data transfer objects used between the presentation layer and the service layer.

　DO (Domain Object): Domain object is a tangible or intangible business entity abstracted from the real world.

PO (Persistent Object): Persistence object, which forms a one-to-one mapping relationship with the data structure of the persistence layer (usually a relational database). If the persistence layer is a relational database, then the data table Each field (or several) in corresponds to one (or several) attributes of PO.

(2) DO

　DO, Domain Object, I usually put it in the Model package, that is, it exists as an entity object of the project, and it is often a class that directly interacts with the ORM framework.

　

DO is often a POJO in actual development, which provides basic Get/Set methods to facilitate data operations. Properties are generally private with permissions, and can only be accessed through Only the G/S method can access attributes. It is also DO that interacts directly with the database.

（3）DTO

　DTO, Date Transfer Object, literally means data transfer class. In fact, it is true. In the process of transferring from server to client, what is needed The complexity of a class is often not something that can be handled by one database table, but requires multiple queries to assemble and combine it into a result. For example:

When the Project is presented in the foreground, you may need to provide ProjectName, UserName (project name, owner name), and the corresponding fields of the Project table in the database may be: ProjectId, UserId. Simply querying the Project table only yields an Id of User. If you need more information about User, you need to query it in conjunction with the User table. The Project class in DO cannot have such detailed and diverse attributes. , the assembled data at this time should be placed in the ProjectDTO class. The example code is as follows:

　

1 public class Project{2       private String projectName;3       private String userid;      
4 }

1 public class User{2     private String username;3     private String userid;4 }

public class ProjectDTO{     private String projectName;     private User user;
}

In this way, you can get the appropriate data by passing ProjectDTO to the front page. The data is displayed. At the same time, because it is an example, it may not be perfect. In actual applications, User in DTO should often be UserDTO, because the User class may contain attributes such as Password.

The above is the detailed content of Database concepts: DO, DTO. For more information, please follow other related articles on the PHP Chinese website!