概念

VO(View Object)

视图对象，用于展示层，作用是把某个指定页面（或组件的所有数据封装起来）。

DTO(Data Transfer Object)

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

DO(Domain Object)

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

PO(Persistent Object)

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对象的映射关系，如果持久层是关系型数据库，那就数据表中每个字段就对应PO的一个（或若干个）属性。

模型

下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置
在这里插入图片描述

用户发出请求，表单的数据在展示层被匹配为VO。
展示层把VO转换为服务层对应方法所要求的DTO，传送给服务层。
服务层首先根据DTO的数据构造一个DO，调用业务方法完成具体业务。
服务层把DO转换为持久层对应的PO（可以使用ORM工具，也可以不用），调用持久层的持久化方法，把PO传递给它，完成持久化操作。
对于一个逆向操作，如读取数据，也是用类似的方式转换和传递。

区别分析

VO与DTO的区别

可能存在一个疑问是，既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对于绝大部分的应用场景来说，DTO和VO的属性基本是一致的，而且它们通常都是POJO（Plain Ordinary Java Object），因此没必要多此一举，但这是实现层面的思维，对于设计层面来说，概念上还是存在VO和DTO，因为两者有着本质上的区别，DTO代表服务层需要接受的数据和返回的数据，而VO代表展示层需要展示的数据。

用一个例子来说明可能会比较容易理解：例如服务层有一个getUser的方法返回一个系统用户，其中有一个属性是gender，对于服务层来说，它只从语义上定义：1-男性，2-女性，0-未定义；而对于展示层来说，可能需要用到“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能还有疑问，在服务层就直接返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许用户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用，而不同的客户端对于表现层的要求有所不同，那么问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，因此，它返回的DTO，不应该表现出与表现形式的耦合。

VO和DTO的应用

不一定非要区分VO和DTO，以下场景可以考虑把VO和DTO二合为一（实现层面上来说）：

当需求非常清晰稳定，而且客户端很明确只有一个时，没有必要非要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可。为什么时VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合，所以，对于前面的例子，DTO对于性别来说，依然不能用“帅哥美女”，这个转换应该依赖与页面的脚本（JS）或其他机制（JSTL，EL，CSS）
即使客户端可以定制，或者存在多个不同的客户端时，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐。

以下场景需要优先考虑VO，DTO并存：

上述场景的反面场景
因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中的某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用架构的自动转换能力带来的开发和维护雄安率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的对比。
如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装。

DTO与DO的区别

首先是概念上的区别，DTO是展示层和服务层之间的数据传输对象（可以认定为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User，对于一个getUser方法而言，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，DO不是简单的POJO，它具有领域业务逻辑。

DTO和DO的应用

在上一节的例子中，可能会有一个疑问：既然getUser方法返回的UserInfo不应该包含password，那么就不应该存在password这个属性定义，但如果同时有一个createUser方法，传入的UserInfo需要包含用户的password，怎么办？在设计层面，展示层向服务层传递的DTO与服务层返回给展示层的DTO在概念上是不同的，但是在实现层面，通常很少这样做（定义两个UserInfo），甚至更多，因为这样做并不见得很明智，我们完全可以设计一个完全兼容的DTO，在服务层接收数据的时候，不该由展示层设置的属性，无论是否设置，服务层都一概忽略，而在服务层返回数据时，不该返回的数据（如用户密码），就不设置对应的属性。

对于DO来说，还有一点需要说明：为什么不在服务层直接返回DO呢？这样可以省去DTO的编码和转换工作，原因如下：

两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。
DO具有一些不应该让展示层知道的数据。
DO具有业务方法，如果直接把DO传递给展示层，展示层的代码就可以绕过服务层直接调用它不应该访问的操作，对于基于AOP拦截服务层来进行访问的控制的机制来说，这问题尤为突出，而在展示层调用DO的业务方法也会因为事务的问题，让事务难以控制。
对于某些ORM框架来说，通常会采用”延迟加载“技术，如果直接把DO暴露给展示层，对于大部分情况，展示层不在事务范围之内，如果其尝试在Session关闭的情况下获取一个未加载的关联对象，会出现运行时异常。
从设计层面来说，展示层依赖与服务层，服务层依赖于领域层，如果把DO暴露出去，就会导致展示层直接依赖领域层，这虽然是单向依赖，但这种跨层依赖会导致不必要的耦合。

对于DTO来说，也有一点必须要进行说明，就是DTO应该是一个”扁平的二维对象“，举个例子来说明：如果User会关联若干个其他实体（例如Address，Account，Region等），那么getUser返回的UserInfo，是否需要把其关联对象的DTO都一并返回呢？如果是这样的话，必然会导致数据传输量的大增，对于分布式应用来说，由于涉设数据在网络上的传输、序列化和反序列化，这种设计更不可接受。如果getUser除了要返回User的基本信息外，还需要返回一个AccountId、AccountName、RegionId、RegionName，那么请把这些属性定义到UserInfo中，把一个”立体“的对象树”压扁“成一个”扁平的二维对象“。

DO和PO的区别

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

DO在某些场景下不需要进行显式持久化，例如利用策略模式设计的商品折扣策略，会衍生出折扣策略的接口和不同折扣策略的实现类，这些折扣策略实现类可以算是DO，但是它们只驻留在静态内存，不需要持久化到持久层，因此，这类DO是不存在对应的PO的。
同样的道理，在某些场景下，PO也没有对应的DO，例如教师Teacher和学生Student存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个TeacherAndStudentPO的PO，但这个PO在业务领域没有任何显示意义，它完全不能与任何DO对应上。这里需要特别声明，并不是所有多对多关系都没有业务含义，这跟具体业务场景有关，例如：两个PO之间的关系会影响具体业务，并且这种关系存在多种类型，那么这种多对多关系也应该变现为一个DO，又如：”角色“和”资源“之间存在多对多的关系，而这种关系很明显会表现为一个DO–”权限“。
在某些情况下，为了某种持久化策略或者性能的考虑，一个PO可能对应多个DO，反之亦然。例如客户Customer有其联系信息Contacts，这里对应两个一对一的DO，但是可能出于性能的考虑（极端情况），为了减少数据库的连接查询操作，把Customer和Contact两个DO数据合并到一张数据表中。反过来，如果一本图书Book，有一个属性是封面Cover，但该属性是一副图片的二进制数据，而某些数据操作不希望把cover一并加载，那么就需要考虑把cover独立到一张数据表中，这样就形成了一个DO对应一个PO的情况。
PO某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现”乐观锁“，PO存在一个version属性，这个version对于DO来说没有任何业务意义，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。

DO和PO的应用

由于ORM框架的功能非常强大而大行其道，而且JavaEE也推出了JPA规范，现在的业务应用开发，基本上不需要区分DO与PO，PO完全可以通过JPA，Hibernate Annotations隐藏在DO之中。虽然如此，但有些问题我们还须注意：

对于DO中不需要持久化的属性，需要通过ORM显式的声明，例如在JPA中，可以利用@Transient声明。
对于PO中为了某种持久化策略而存在的属性，例如version，由于DO，PO合并了，必须在DO中声明，但由于这个属性对DO是没有任何业务意义的，需要让该属性对外隐藏起来，最常见的做法是把该属性的get/set方法私有化，甚至不提供get/set方法。