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.
[3].用户1418372.第一节 DDD领域驱动概述[EB/OL].https://cloud.tencent.com/developer/article/1336541
网友评论