领域驱动模型VO、DTO、DO、PO 概念

展示层，它的作用是把某个指定页面(或组件)的所有数据封装起来。

DTO(Data Transfer Object)数据传输对象

这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但是这里，主要用于展示层与服务层之间的数据传输对象。

比如一张表有100个字段，那么对应的DTO就有100个属性(大多数情况下，DTO内的数据来自多张表)。但是view层只需要显示10个字段，没有必要把整个PO对象传递到 client，这时我们就可以用只有这10个属性的DTO来传输数据到 client，这样也不会暴露 server 端的表结构。到达客户端后，如果用这个对象来对应界面展示，那么此时它的身份就转为 VO。

DO(Domain Object)领域对象

就是从现实世界中抽象出来的有形或无形的业务实体。

PO(Persistent Object)：持久化对象

它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段就对应PO的一个属性。

对于以上概念的理解，可能还不能形成一种抽象化思维，我们通过一个时序图建立模型来描述上述对象在三层架构应用中的位置：

• 提交请求(可能是填写表单)，表单上的数据在展示层被匹配为 VO。
• 服务层把 VO 转换为服务层对应方法所要求的 DTO，传送给服务层。
• 服务层首先根据 DTO 的数据构造一个 DO (或重建)，调用 DO 的业务方法完成具体业务。
• 服务层把 DO 转换为持久层对应的 PO(一般使用 ORM 工具)，调用持久层的持久化方法，把 PO 传递给它，完成持久化操作。

对于一个逆向操作，如读取数据，也是用类似的方式转换和传递。

VO 与 DTO 对比

VO 与 DTO 的区别

在这里我们可能会问：既然 DTO 是展示层与服务层之间传递数据的对象，为什么还要一个 VO 呢?

是的，对于绝大部分的应用场景来说，DTO 和 VO 的属性值基本是一致的，而且他们通常都是 POJO，因此没必要多此一举。但不要忘记这是实现层的思维，对于设计层面来说，概念上还是应该存在 VO 和 DTO，因此两者有着本质的区别，DTO 代表服务层需要接收的数据和返回的数据，而 VO 代表展示层需要显示的数据。

用一个例子来说明可能会比较容易理解：

例如：Service 层有一个 getUser 的方法返回一个系统用户，其中有一个属性是 gender(性别)，对于 Service 层来说，它只从语义上定义：1-男性、2-女性、0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性、“美女”代表女性、“秘密”代表未指定。

说到这里，可能你还会反驳，在服务层直接返回“帅哥、美女”不就行吗?对于大部分应用来说，这不是问题，但设想以下，如果需求允许客户可以定制风格，而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的 DTO，不应该出现与表现形式的耦合。

理论归理论，这到底还是分析设计层面的思维，是否在具体实现

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!