This article discusses the development process objects which we often used: VO, DTO, DO, PO ;
due to the project and each person's naming convention, but here these concepts elaborated.
concept:
VO (View Object): a view object for display layer, it is the role of a given 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, with which the persistence layer (usually a relational database) data structure is formed one to one mapping relationship, if the persistence is a relational database, the data for each field in the table ( or several) on the PO corresponding to one (or several) properties.
model:
下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置
l requesting user (fill out a form may be), to form VO data is matched in the presentation layer.
l VO to the display layer corresponding to layer into a service method as claimed in DTO, to the service layer.
The first layer l DTO service configuration data (or reconstruction) a DO, DO call business methods to accomplish specific business.
l DO service layer 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.
l For a reverse operation, such as read data, is transmitted and converted in a similar manner, slightly.
The difference between the VO and DTO
大家可能会有个疑问（在笔者参与的项目中，很多程序员也有相同的疑惑）：既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。
用一个例子来说明可能会比较容易理解：例如服务层有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。
理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。VO and DTO applications
上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。
在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）：l When the 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 duties of the service layer and the presentation layer should not still be coupled, so, for the previous example, you can easily understand, DTO for "sex", it still can not use the "hotties", the conversion should depend on page scripts (such as JavaScript) or other mechanisms (JSTL, EL, CSS)
l 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), can also make VO retire
The following scenarios need to give priority VO, DTO co-exist:
l opposite scenario above scenario
When l for some technical reasons, such as a framework (such as Flex) provides POJO automatically convert certain UI Field, consider the definition of a VO at implementation level, this trade-off depends entirely on the ability to use automatic conversion framework to bring development and maintenance efficiencies than the decline between development and maintenance efficiency and design bring the VO do one more thing.
L If all of the data page appears a "large view", which consists of the large view of the need to call a plurality of services, a plurality of return assembled DTO (of course, it can also provide a large view of a disposable return DTO be substituted by a service layer but in the service layer to provide such a method is appropriate, we need to balance the design level).
The difference between the DTO and DO
首先是概念上的区别，DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User（对于DTO和DO的命名规则，请参见笔者前面的一篇博文），对于一个getUser方法来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，正如第一篇系列文章所说，DO不是简单的POJO，它具有领域业务逻辑。DTO and DO application
从上一节的例子中，细心的读者可能会发现问题：既然getUser方法返回的UserInfo不应该包含password，那么就不应该存在password这个属性定义，但如果同时有一个createUser的方法，传入的UserInfo需要包含用户的password，怎么办？在设计层面，展示层向服务层传递的DTO与服务层返回给展示层的DTO在概念上是不同的，但在实现层面，我们通常很少会这样做（定义两个UserInfo，甚至更多），因为这样做并不见得很明智，我们完全可以设计一个完全兼容的DTO，在服务层接收数据的时候，不该由展示层设置的属性（如订单的总价应该由其单价、数量、折扣等决定），无论展示层是否设置，服务层都一概忽略，而在服务层返回数据时，不该返回的数据（如用户密码），就不设置对应的属性。
对于DO来说，还有一点需要说明：为什么不在服务层中直接返回DO呢？这样可以省去DTO的编码和转换工作，原因如下：L The difference in nature and may cause not correspond to each other, a DTO may correspond to multiple DO, and vice versa, even the two-many relationship exists.
l DO have some presentation layer should not be allowed to know the data
l DO have a business method, if passed directly to the DO to the presentation layer, layer to show the code can bypass the service layer calls directly manipulate it should not have access, for the mechanism for access control based AOP intercept service layer, this the problem is particularly prominent in the presentation layer DO call a business method will be because the problem transaction, so the transaction is difficult to control.
For some l 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, the presentation layer is not within the scope of a transaction (Open session in view large in some cases not a design 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.
l 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 dependent layer will cause unnecessary coupling.
For DTO is also one thing must be stated that 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和PO在绝大部分情况下是一一对应的，PO是只含有get/set方法的POJO，但某些场景还是能反映出两者在概念上存在本质的区别：l 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, but they only reside in static memory, need not persisted to the persistence, so that such is not the corresponding PO DO exist.
l Similarly, in some scenarios, PO no corresponding DO, for example, the presence of many-teachers and students Teacher Student, in a relational database, the performance of the relationship requires an intermediate table, it corresponds to a TeacherAndStudentPO the PO, but this PO do not have any real significance in the field of business, its totally not correspond with any DO. 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."
L 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 l PO DO not make any sense, these property values may be in order to address some persistence strategy and existing data in order to achieve "optimistic locking", PO presence such as a version attribute to the version for DO said 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
由于ORM框架的功能非常强大而大行其道，而且JavaEE也推出了JPA规范，现在的业务应用开发，基本上不需要区分DO与PO，PO完全可以通过JPA，Hibernate Annotations/hbm隐藏在DO之中。虽然如此，但有些问题我们还必须注意：l DO For unnecessary persistent attributes need to explicitly declare the ORM, such as: In JPA may be utilized @Transient statement.
l 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, you need to let the Foreign property Hide up, the most common practice is to get the property / set methods of privatization, 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 using reflection to invoke instances DO DO null argument constructor function, and then using a JavaBean specification of reflecting the set methods for each property value is set, if not set explicitly declared method, or a method to set the private, are unable to initialize Hibernate lead to DO, so abnormal and feasible approach is to set the property is protected method set to run the event.
l for a corresponding number of PO DO, DO, or a PO corresponding to a plurality of scenes, and property level lazy loading, Hibernate provides good support, please refer to relevant information Hibnate.