浅析VO、DTO、DO、PO

一、概念介绍

POJO（plain ordinary java object） ：

简单java对象，个人感觉POJO是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。一个POJO持久化以后就是PO，直接用它传递、传递过程中就是DTO，直接用来对应表示层就是VO。（POJO、PO、DTO、VO都是处理流程中的名字，不是PO对应一个POJO，DTO对应一个POJO，VO对应一个POJO在有些情况下PO、DTO、VO是指同一个POJO）。

VO（View Object）：

视图对象，主要对应界面显示的数据对象。它的作用是把某个指定页面（或组件）的所有数据封装起来。如果是一个DTO对应一个VO，则DTO等价于VO;但是如果一个DTO对应多个VO，则展示层需要把VO转换为服务层对应方法所要求的DTO，传送给服务层，从而达到服务层与展示层解耦的效果。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。

​BO（business object）：

业务对象，主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。比如一个简历，有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO。这样处理业务逻辑时，我们就可以针对BO去处理。BO包括包含方法的实体对象(Entity Object)和不包含方法的值对象(VO)。

DTO（Data Transfer Object）：

数据传输对象，主要用于远程调用等需要大量传输对象的地方。比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。在这里，我泛指用于展示层与服务层之间的数据传输对象。

DO（Domain Object）：

领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。它用来接收数据库对应的实体，是一种抽象化的数据状态，介于数据库与业务逻辑之间。一般在业务逻辑层（Service）对数据库（SQL） 进行访问时，用于接收数据。xxxDO，xxx即为数据表名。另外，DO与Entity的不同点就是DO是与数据库存在着某种映射关系的Entity，总的来说DO是Entity的一种。

PO（Persistent Object）：

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。最形象的理解就是一个PO就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。

 

二、区别

1、VO与DTO的区别

概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据

2、DTO与DO的区别

DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象

3、DO与PO的区别

DO和PO在绝大部分情况下是一一对应的，PO是只含有get/set方法的POJO，但某些场景还是能反映出两者在概念上存在本质的区别：

​
DO在某些场景下不需要进行显式的持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略实现类，这些折扣策略实现类可以算是DO，但它们只驻留在静态内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。

同样的道理，某些场景下，PO也没有对应的DO，例如老师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何现实的意义，它完全不能与任何DO对应上。

某些情况下，为了某种持久化策略或者性能的考虑，一个PO可能对应多个DO，反之亦然。
PO的某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现“乐观锁”，PO存在一个version的属性，这个version对于DO来说是没有任何业务意义的，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。
​

总结：DO和PO是两个层级的概念，两者存在一对一、一对多和多对一的关系。这两个层级的字段，DO不需要包括全部的PO，比如PO中的创建、删除标记、自动生成的ID等，PO可以不用关注。

三、各层数据对象的职责和转换过程

基础层

​入参是DO，内部将DO转化成PO进行数据库的增删改查。

执行结果用PO去映射，再转化为DO作为基础层的返回值。

先建立DO和PO的映射：

当DO数据需持久化时，仓储服务会将DO转换为PO，

当DO需初始化时，仓储服务从数据库获取数据形成PO，并将PO转换为DO。

大多数情况下PO和DO一一对应。但也存在DO和PO多对多，在DO和PO数据转换时，需数据重组。

比如时间范围查询时，会有辅助字段，如：beginTime和endTime，PO这怎么处理？我们的处理方式是增删改用PO，查询时候用QueryPO，QueryPO继承了PO并额外增加用于查询的辅助字段（比如时间、集合、模糊查询等）。

有的查询功能，比如按照名称查询，查询条件就是name，DTO、DO和PO是一样的，也需要在每一层都去转化一下么？我们把查询时的对象命名为QueryPO，从用户接口层到基础层的入参都是这一个，这样可以么？是否要做数据转换？主要是考虑解耦，这样各层不必受其它层的数据限制，它类似齿轮，通过数据转换来做适配。

如果从前端到后端数据对象都是一样的，用一个对象其实也是可以的。要结合自己的场景来分析。一般聚合根用的少，很多情况聚合根要作为对象传到基础层。

​领域层

入参是DO，返回值是DO。

DO是实体和值对象的数据和业务行为载体，承载基础的核心业务逻辑。通过DO和PO转换可完成数据持久化和初始化。

应用层

入参是DO，返回值是DO。

如果需调用其它微服务的应用服务，DO会转换为DTO，完成跨微服务的数据组装和传输。用户接口层先完成DTO到DO的转换，然后应用服务接收DO进行业务处理。如果DTO与DO是一对多的关系，就需进行DO数据重组。

用户接口层

入参是DTO，内部将DTO转化为DO后调用应用层

将应用层的结果转化为VO后返回给前台

完成DO和DTO的互转，完成微服务与前端应用数据交互及转换。

Facade服务会对多个DO对象进行组装，转换为DTO对象，向前端应用完成数据转换和传输。

​

前端应用

主要是VO。展现层使用VO进行界面展示，通过用户接口层与应用层采用DTO对象进行数据交互。

 

作者来源：DOKER 多克