简单说下VO、PO、DO、DTO的主要区别及应用场景

  好久没有更新文章了，最近刚入职熟悉了几个项目，因此看了很多代码，发现里面有很多实体采用了VO、DO、DTO这样的名称结尾，之前大致了解过他们的含义以及他们的使用场景，今天特地整理一下记录下来。

概要

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

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

DO： 即 Domain Object，是指领域对象，就是从现实世界中抽象出来的有形或无形的++业务实体++。

DTO： 即 Data Transfer Object，是指数据传输对象，这个概念来源于 J2EE 的设计模式，原来的目的是为了 EJB 的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载。我们可以理解为用于展示层与服务层之间的数据传输对象。

三层架构模型

  下面是用我们比较熟悉的三层架构时序图模型来让大家一起了解上述对象在三层架构应用中的位置。

大致过程

• 用户发出请求（可能是输入账户密码进行登录），表单的数据在展示层被匹配为 VO。
• 展示层把 VO 转换为服务层对应方法所要求的 DTO，传送给服务层。
• 服务层首先根据 DTO 的数据构造（或重建）一个 DO ，调用 DO 的业务方法完成具体业务。
• 服务层把 DO 转换为持久层对应的 PO（可以使用 ORM 工具，也可以不用），调用持久层的持久化方法，把 PO 传递给它，完成持久化操作。
• 而对于一个逆向操作，比如读取数据，也是用类似的方式进行转换和传递，此处不做过多讲述。

区别与应用

VO 与 DTO 的区别

  大家可能会有个疑问：既然 DTO 是展示层与服务层之间传递数据的对象，为什么还需要一个 VO 呢？对！对于绝大部分的应用场景来说，DTO 和 VO 的属性值基本是一致的，而且他们通常都是 POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在 VO 和 DTO&#