Concept VO, DTO, DO, PO, the difference and usefulness

First, the concept

VO (View Object): view layer , presentation layer is used, its role is to a specified page (or component) of all of the data package together.

DTO (Data Transfer Object): data transfer object , this concept comes J2EE design patterns, the original purpose is to provide a distributed application EJB data entity coarse-grained, in order to reduce the number of the distributed calls, thereby improving call distributed performance and reduced network load, but here, I refers to data transfer objects between the presentation layer and the service layer.

DO (Domain Object): domain objects , is abstracted from the real world, tangible or intangible business entity.

PO (Persistent Object): persistent object (e.g.: Entity, the bean) , he and persistence layer (usually a relational database) data structure is formed one to one mapping relationship, if the persistence is a relational database, then the data each field in the table (or several) on the PO corresponding to one (or several) properties.
 

A timing chart below to create a simple model to describe the position of the target in a three-tier application: 

Flow chart to explain: 

1. The requesting user (fill out a form may be), to form VO data is matched in the presentation layer.
2. The presentation layer corresponding to layer into a service VO method as claimed in DTO, to the service layer.
3. DETAILED first complete business service layer data structure according DTO (or reconstruct) a DO, DO, call a business method.
4. The service layer DO is converted to the corresponding persistence PO (ORM tool may be used, can not), the persistence persistence method call, it passes to the PO, persistence operation is completed.

For a reverse operation, such as read data, it is transmitted and converted in a similar manner.

 

The difference between the VO and DTO

1. You may have a doubt (I participate in the project, many programmers have the same doubts): Since DTO is subject to transfer data between the presentation layer and the service layer, why do we need a VO it? Correct! For most of the scenarios, the property values ​​of DTO and VO is basically the same, and they are usually POJO, so no need to bother, but do not forget that this is achieved the level of thinking, the design level, the concept of or should exist on VO and DTO, because both are essentially different, DTO represents the service layer needs to receive the data and return data, and data presentation layer represents the VO to be displayed.

2 will be described with an example may be more easily understood: the service layer, for example, a method of getUser system returns a user, a property which is gender (Sex), for the service layer, the definition of only semantically: 1 - male, 2 female, 0-unspecified, and for the presentation layer, it may be necessary for male with "male", with "beauty" for women, with a "secret" for unspecified. Here, you might also argue, direct returns "hotties" in the service layer is not on line yet? For most applications, this is not a problem, but imagine if demand allows customers to customize styles, and different styles for "Sex" is not the same performance, or the service at the same time for multiple clients using (different portal ), and different requirements for client presentation layer are different, then the problem came. Again, back to the design level of analysis, from a single responsibility principle point of view, the service layer is responsible only for the business, irrespective of the particular form of expression, therefore, it returns the DTO, should not be coupled with the emergence of forms.

3. Theoretical return theory, which in the end is the level of analysis and design thinking, do we have to do so at the level it achieved? One size fits all approach is often not worth the candle, I'll analyze the following applications how to make the right choice.

VO and DTO applications

The above are just used a simple example to illustrate the difference between VO and DTO in concept, this section will tell you how to make the right choice in the application.
In the following scene before we can consider VO and DTO two-in-one (note: to achieve levels):

When demand is very clear and stable, and the client is very clear there is only one time, there is no need to distinguish VO and DTO area, VO can retire at this time, you can use a DTO, VO Why is retired and not DTO? Back to the design level, the service layer because the responsibility is still not coupled with the presentation layer, so, for the previous example, you can easily understand, DTO for "sex", it still can not use the "hotties", the conversion should not rely and page scripts (such as javaScript) or other mechanisms (JSTL, EL, CSS).
Even if the client can be customized, or there are multiple different client, if the client is able to achieve some kind of conversion technology (script or other mechanism), it can also make VO retreat.

The following scenarios need to give priority VO, DTO co-exist:

The above scenario reverse scenario
for some technical reasons, such as a frame (e.g., the Flex) provided to automatically convert POJO UI certain FieId, consider the implementation level VO defined, this tradeoff depends entirely on the use of frame brings the ability to develop and maintain automatic conversion efficiency and design to enhance the contrast between a multi-drop VO do the things that bring development and maintenance efficiency.
If the page appears a "big view", which consists of all of the data in this large view of the need to call multiple services, multiple DTO return to the assembly (of course, it can also provide a one-time return a large view of DTO through the service layer in place, but in the service layer to provide such a method is appropriate, need to balance the design level).

The difference between the DTO and DO

The first is the conceptual distinction, DTO is data transfer objects between the presentation layer and the service layer (may be considered to be an agreement between the two), while DO is an abstraction of the real world a variety of business roles, which leads to two by differences in the data, such as UserInfo and user (for naming DTO and DO, see the author's earlier blog post), for a getUser method, it should never return the user's password in nature, and therefore UserInfo a password data at least one less than the User. In domain-driven design, just as the first article in the series said, DO is not a simple POJO, it has areas of business logic.

DTO and DO application

1. From an example, the careful reader may find the question: If the method returns UserInfo getUser should not contain password, then the password should not exist in this attribute definition, but at the same time if there is a method createUser, passing the UserInfo need to include the user's password, how do? In the design level, the presentation layer transferred to the service layer and the service layer DTO DTO returned to the presentation layer in the concept is different, but in the implementation level, we usually rarely do (define two UserInfo, or even more) , because it does not seem very wise, we can design a fully compatible DTO, when the service layer receives the data, property should not be set by the presentation layer (such as the total price of the order should its price, quantity discount and other decisions), regardless of whether the setting presentation layer, service layer are not and will ignore, and in return the service layer data, data (such as user passwords) should not go back, do not set the corresponding property.
2. For DO, the more thing: Why not return to direct the service layer DO it? Such encoding can be omitted and conversion work DTO for the following reasons:

The difference in nature may cause not correspond to each other, a DTO may correspond to multiple DO, and vice versa, even the two-many relationship exists.
DO have some presentation layer should not be allowed to know the data.
DO have a business method, if passed directly to the DO to the presentation layer, presentation layer of code that can bypass the service layer called directly manipulate it should not have access, for the mechanism for access control based AOP intercept service layer, this problem especially, in the presentation layer DO call a business method will be because the problem transaction, so the transaction is difficult to control.
For some ORM frame (e.g., the Hibernate), the often use "lazy loading" technique, if the DO directly exposed to the presentation layer, for the most part, not within the display range of the layer of the transaction (Open session in view in most design is not a case worthy of praise), if it attempts to get the case closed Session object associated unloaded, an exception (for Hibernate, it is LazyInitiliaztionException runtime) will appear.
From the design perspective, the presentation layer depends on the service layer, service layer depends on the domain layer, if exposed to the DO, will lead the presentation layer is directly dependent on the field level, although this is still a one-way dependence, but this cross-layer dependence can lead to unnecessary coupling.

For DTO, there is also little to be explained, is the DTO should be a "flat two-dimensional object", give an example to illustrate: If you associate a number of other entities (such as Address, Account, Region, etc.) User will then getUser () returned UserInfo, whether it is necessary to DTO objects that are associated together to return it? If so, inevitably lead to increase the amount of data transmission, for distributed applications, since the transmission data over the network directed, serialization and deserialization, this design is more unacceptable. If getUser addition to the basic information of the User return, but also a need to return AccountId, AccountName, RegionId, RegionName, then, to make these attributes define the UserInfo, to a "three-dimensional" object tree "collapsed" into a "flat the two-dimensional object, "the author of the project is currently involved in a distributed system that willy-nilly, all associated objects are converted to an object DTO object tree and return the same structure, resulting in very slow performance .

The difference between DO and PO

DO and PO in most cases is one to one, PO containing only POJO get / set methods, but some scenes still reflect the difference between the two concepts exist in nature:

DO in some scenarios do not require explicit persistence, for example, by discounts on merchandise strategy pattern design policy, the policy will be derived discount Discount different interfaces and implementation classes, these classes can be regarded as a discount policy implementation DO, they only reside in static memory, need not persisted to the persistence, so that such is not the corresponding PO DO exist.
By the same token, in some scenarios, PO there is no corresponding DO, such as the presence of many-teacher Teacher and student Student, In a relational database, this relationship need to show a middle table, it corresponds to a TeacherAndStudentPO the PO, but this PO do not have any real significance in the field of business, it can not be completely on any DO correspondence. It must declare that not all many relationships have no business meaning, which with about specific business scenarios, such as: the relationship between the two PO affect specific business, and there are many types of this relationship, then this many relationships should also be expressed as a DO, Another example: many relationship exists between "role" and "resources", and this relationship is clearly manifested as a DO-- "privilege."
In some cases, for some persistent policy or performance considerations, PO may correspond to a plurality of DO, and vice versa. Such as customer Customer Contacts have their contact information, here are two DO-one relationship, but perhaps due to performance considerations (in extreme cases, the right for example), in order to reduce connection query the database, the Customer and two Contacts DO data incorporated into a data table. Conversely, if a Book Book, there is a cover cover property, but the property is a picture of binary data, but some queries do not want to cover operating load together, thereby reducing the overhead of disk IO, and assuming ORM framework does not support attribute-level lazy loading, then we need to consider the cover to a separate data table to go, thus forming a DO to deal with a case of the PO.
Some attribute values ​​for DO PO does not make any sense, these property values ​​may be in order to solve some of the data persistence strategy exists, in order to achieve "optimistic locking", PO exist such as a version of the property, this version is for DO there is no business sense, it should not exist in the DO. Similarly, DO also may not require the presence of persistent attributes.

DO and PO applications

Since the function ORM framework is very powerful and popular, but also introduced a JavaEE JPA specifications, current business application development, basically you do not need to distinguish between DO and PO, PO entirely by JPA, Hibernate Annotations / hbm hidden in the DO. Nevertheless, we must also pay attention to some problems:

For DO unnecessary persistent attributes need to explicitly declare the ORM, such as: In JPA you may be utilized @Transient statement.
For the PO in order to some persistence strategy exists properties, such as version, due DO, PO merger must be declared in the DO, but because of this property of DO is not any business sense, we need to let the Foreign property hidden the most common practice is to get the property / set methods of privatization, it does not even provide get / set methods, but for Hibernate, this requires special attention, due to Hibernate reads data from the database to convert DO, is the use of examples reflection mechanism to call DO DO null argument constructor function, and then using the reflected JavaBean specification set methods for each property value is set, if not set explicitly declared method, or a method to set the private, will lead to unable to initialize Hibernate DO, so abnormal and feasible approach is to set the property is protected method set to run the event.
For a corresponding number of PO DO, or a corresponding number of PO DO scene, as well as property-level lazy loading, Hibernate provides good support, please refer Hibnate relevant information.
----------------
Disclaimer: This article is CSDN blogger "zhuguang10 'original article, follow the CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source link and this statement. .
Original link: https: //blog.csdn.net/zhuguang10/article/details/90346751

 

Second, the concept described in detail and differences PO VO BO DTO DAO and the POJO

To be honest, I believe that for students new to PO, VO, BO, DTO, DAO and POJO these concepts, the Mets have a "This is what the hell?" Feeling, can be described as foggy, I do not know Jinxi He Xi! Now, let we go and uncover the "X" O veil to see their true colors. First, a map Chou Chou:

The first one: DAO

　　DAO (Data Access Object) data access object, it is an object-oriented database interface persistence layer is responsible for the operation, provides an interface for the business layer, primarily used to package access to the database, nothing less common operations CURD. We can also think of a corresponding one of DAO POJO object, which is located in the middle of the business logic and database resources, the database may be incorporated PO related operations.

2nd: PO

　　PO (Persistent Object) object persistence layer, which is composed of a set of properties and methods get and set properties of the composition, the easiest PO is a database record corresponds to a table (that is, we can be a database table a record layer understood as a persistent object), a plurality of recording can be set PO, PO should not contain any database operation. PO attribute field is a database table with one to one, in addition to the need to achieve objects PO serial interfaces.

3rd: BO

　　BO (Business Object) business layer objects, the software is simple real-world abstraction, usually located in the middle layer. BO main function is to encapsulate the business logic of an object, the object may include one or more other objects. For example, a resume of each resume includes educational experience, project experience, etc., we can make educational experience and project experience correspond to a PO, BO so when we resume processing the object to correspond resume, so that each PO BO contain these can be.

4th: VO

　　VO（Value Object）值对象，通常用于业务层之间的数据传递，和 PO 一样也是仅仅包含数据而已，但 VO 应该是抽象出的业务对象，可以和表对应，也可以不对应，这根据业务的需要。 如果锅碗瓢盆分别为对应的业务对象的话，那么整个碗柜就是一个值对象。此外，VO 也可以称为页面对象，如果称为页面对象的话，那么它所代表的将是整个页面展示层的对象，也可以由需要的业务对象进行组装而来。

第 5 个：DTO

　　DTO（Data Transfer Object）数据传输对象，主要用于远程调用等需要大量传输对象的地方，比如我们有一个交易订单表，含有 25 个字段，那么其对应的 PO 就有 25 个属性，但我们的页面上只需要显示 5 个字段，因此没有必要把整个 PO 对象传递给客户端，这时我们只需把仅有 5 个属性的 DTO 把结果传递给客户端即可，而且如果用这个对象来对应界面的显示对象，那此时它的身份就转为 VO。使用 DTO 的好处有两个，一是能避免传递过多的无用数据，提高数据的传输速度；二是能隐藏后端的表结构。常见的用法是：将请求的数据或属性组装成一个 RequestDTO，再将响应的数据或属性组装成一个 ResponseDTO.

第 6 个：POJO

　　POJO（Plain Ordinary Java Object）简单的 Java 对象，实际就是普通的 JavaBeans，是为了避免和 EJB（Enterprise JavaBean）混淆所创造的简称。POJO 实质上可以理解为简单的实体类，其中有一些属性及其getter和setter方法的类，没有业务逻辑，也不允许有业务方法，也不能携带有connection之类的方法。POJO 是 JavaEE 世界里面最灵活的对象，在简单系统中，如果从数据库到页面展示都是 POJO 的话，它可以是 DTO；如果从数据库中到业务处理中都是 POJO 的话，它可以是 BO；如果从数据库到整个页面的展示的话，它也可以是 VO.

扩展阅读：

　　在实际的项目中，我们还会遇到一个常见的对象，那就是 Entity 实体对象，它对应数据库中的表，我们可以简单的理解为一个表对应一个 Entity，同样以交易订单表 Order 为例，如果这个表有 25 个字段，那么这个 OrderEntity 对象里面也要含有 25 个对应的属性。