VO、DTO、DO、PO区分 VO、DTO、DO、PO区分

ABSTRACT 目前的三层架构的系统开发，在不同的层都会定义不同的对象。虽然各个层次中的对象信息都差不多，但还是得分层区别对待。因此，有必要研究一下三层架构下各层对象之间的具体差异，以便日后开发能够对系统架构理解更深刻。
INTRODUCTION 首先给出四个对象的全称[1]：

VO【View Object】视图对象-用于展示层，将某个指定的页面（或者组建）封装起来。
DTO【Data Transfer Object】数据传输对象-泛指视图层和服务层之间的数据传输对象。
DO【Domain Object】领域对象-现实生活中抽象出来的有形的或无形的业务实体。
PO【Persistent Object】持久化对象-跟持久层【通常是关系型数据库】形成一一映射的关系，如果持久层是关系型数据库，那么数据库表中的每个字段则对应PO中的每个属性。

四个对象之间的在三层架构中的交互时序图如图1所示：

文章图片
图1 四个对象之间的在三层架构中的交互时序图领域模型中的实体类分为四种类型：VO、DTO、DO、PO，各种实体类用于不同业务层次间的交互，并会在层次内实现实体类之间的转化。
业务分层为：视图层（VIEW+ACTION），服务层（SERVICE），持久层（DAO） [2]
ANALYSIS 各个对象之间的关系和异同分析：
1.VO和DTO
DTO为数据传输对象，既然是放在网络中传输的，因此，该对象必然不能太臃肿，否则信息太多必然会影响数据传输。而VO作为视图层的视图对象，应前端要求，同时为了满足用户对丰富度的要求，会存放很多信息进行展示，使得产品丰富化。因此VO和DTO一般情况下会使用两个有点差别的对象，但信息基本一致，DTO就是根据VO构造的，他们都是POJO。
对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。表现层可以根据需求进行调整，但是DTO传回来的数据是一致的，具体的展示逻辑是从VO的字段定义中决定的。从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。
2. DTO和DO
首先是概念上的区别，DTO是展示层和服务层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别。
例如UserInfo和User，前者是DTO中的对象，而后者是DO中的对象。对于一个getUser方法来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，DO不是简单的POJO，它具有领域业务逻辑[1]。
从数学维度看，DTO和DO更像多对多的映射关系。一个DTO中可能包含多个DO中的属性，同时一个DO可能对应多个DTO。
从业务分层角度来说，DO中可能有一些不想让展示层知晓的属性，同时DO中也可能包含一些不能让展示层直接调用的方法。
3. DO和PO
DO和PO在绝大部分情况下是一一对应的，PO是只含有get/set方法的POJO，但某些场景还是能反映出两者在概念上存在本质的区别：
DO在某些场景下不需要进行显式的持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略实现类，这些折扣策略实现类可以算是DO，但它们只驻留在静态内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。
同样的道理，某些场景下，PO也没有对应的DO，例如老师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何现实的意义，它完全不能与任何DO对应上。这里要特别声明，并不是所有多对多关系都没有业务含义，这跟具体业务场景有关，例如：两个PO之间的关系会影响具体业务，并且这种关系存在多种类型，那么这种多对多关系也应该表现为一个DO，又如：“角色”与“资源”之间存在多对多关系，而这种关系很明显会表现为一个DO——“权限”。
REFERENCE [1]. 随风而逝,只是飘零.浅析VO、DTO、DO、PO的概念、区别和用处[EB/OL].https://www.cnblogs.com/zxf330301/p/6534643.html
[2]. wangxin0314.实体类（VO，DO，DTO）的划分[EB/OL].https://blog.csdn.net/wangxin1982314/article/details/51954264.
【VO、DTO、DO、PO区分】[3].用户1418372.第一节 DDD领域驱动概述[EB/OL].https://cloud.tencent.com/developer/article/1336541