领域模型中的

领域模型中的实体类分为四种模型：VO、DTO、DO、PO，各种实体类用于不同业务层次间的交互，并会在层次内实现实体类之间的转化。

业务分层为：视图层(VIEW+ACTION)、服务层(SERVICE)、持久层(DAO)，相应各层间实体的传递如下：

VO: Value Object , 表现对象

用于表示一个与前端进行交互的 java 对象。有的朋友也许有疑问，这里可不可以使用 PO 传递数据？实际上，这里的 VO 只包含前端需要展示的数据即可，对于前端不需要的数据，比如数据创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在 VO 中体现出来。

DTO: Data Transfer Object , 数据传输对象

用于表示一个数据传输对象。DTO 通常用于不同服务或服务不同分层之间的数据传输。DTO 与 VO 概念相似，并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同，这个不同主要是设计理念上的，比如 API 服务需要使用的 DTO 就可能与 VO 存在差异

比如我们一张表有 100 个字段，那么对应的 PO 就有 100 个属性。但是我们界面上只要显示 10 个字段，客户端用 WEB service 来获取数据，没有必要把整个 PO 对象传递到客户端，这时我们就可以用只有这 10 个属性的 DTO 来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为 VO

DO: Domain Object, 领域对象

就是从现实世界中抽象出来的有形或无形的业务实体。一般和数据中的表结构对应。

DTO 与 DO 区别

首先是概念上的区别，DTO 是展示层和服务层之间的数据传输对象(可以认为是两者之间的协议)，而 DO 是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别。

例如：UserInfo 和 User ，对于一个 getUser 方法来说，本质上它永远不应该返回用户的密码，因此 UserInfo 至少比 User 少一个 password 的数据。而在领域驱动设计中，DO 不是简单的 POJO，它具有领域业务逻辑。

PO: Persistant Object,持久化对象

在 o/r 映射的时候出现的概念，如果没有 o/r 映射，没有这个概念存在了。通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的 java 对象。最简单的 PO 就是对应数据库中某个表中的一条记录，多个记录可以用 PO 的集合。PO 中应该不包含任何对数据库的操作。（当需要满足 Java 对象得到持久化（即保存）的需求）

DO 和 PO 的区别

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

• 同样的道理，某些场景下，PO 也没有对应的 DO，例如老师 Teacher 和学生 Student 存在多对多的关系，在关系数据库中，这种关系需要表现为一个中间表，也就对应有一个 TeacherAndStudentPO 的 PO，但这个 PO 在业务领域没有任何现实的意义，它完全不能与任何 DO 对应上。这里要特别声明，并不是所有多对多关系都没有业务含义，这跟具体业务场景有关，例如：两个 PO 之间的关系会影响具体业务，并且这种关系存在多种类型，那么这种多对多关系也应该表现为一个 DO，又如：“角色”与“资源”之间存在多对多关系，而这种关系很明显会表现为一个 DO——“权限”。

DAO: Data Access Object , 数据访问对象

当模型执行完业务逻辑后，我们便要把模型中的数据保存到数据库中。如果我们直接把和数据库相关的代码放在模型里，会使得以后的维护相当的麻烦; 使用 DAO 访问数据库，包括插入、更新、删除、查询等操作。

DAO 一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。

ORM: object-relational mapping,

与 DAO 类似，ORM 也是一种封装数据访问的概念。然而 ORM 不像 DAO 只是一种软件设计的指导原则，强调的是系统应该层次分明。ORM 更像是一种工具，有着成熟的产品，比如 nodejs 界非常有名的 sequlize，以及很多 PHP 框架里自带的 ORM 库。他们的好处在于能将你程序中的数据对象自动地转化为关系型数据库中对应的表和列，数据对象间的引用也可以通过这个工具转化为表之间的 join，而 Hibernate 甚至提供一套他们自己的数据查询语言 HQL 来解决复杂的查询问题。

使用 ORM 的好处就是使得你的开发几乎不用接触到 SQL 语句。创建一张表，声明一个对应的类，然后你就只用和这个类的实例进行交互了，至于这个对象里的数据该怎么存储又该怎么获取，通通不用关心。

DAO 和 ORM 的区别

• 1. 所谓 DAO 层一般是从系统分层结构出发来说的，即把数据存取操作到集中到 DAO 层，以便于维护和逻辑清晰，而且通常移植数据库的时候，如果系统合理分层了，则大部分工作将会集中在 DAO 层，这样比较容易操作
• 2. 而 ORM 是针对开发而言的，就像面向过程和面向对象开发一样，是一种处理问题的方式。ORM 的目的是使数据操作能像操作对象那样方便（其实有时候不一定更方便，更准确地说，应该是让程序员能够运用过面向对象的思想来操作数据对象），通常 ORM 会做到将数据库表映射成对象，封装一些基本的数据操作，以及提供一些如级联查询和保存之类帮助开发的扩展功能。

DAO 层在实现时可以选择使用 ORM 框架，也可以使用直接的数据库操作，有时候因为性能要求只能直接操作数据的。

AO: Application Object , 应用对象

• AO 是一个较为笼统的概念，因为太过于常见而并没有刻意的去描绘它的细节。举一个很简单的栗子：控制层（Controller） 在 业务逻辑层（Service） 查询一条或多条数据，这个数据的传输过程的运载就是 AO 完成。在正常的业务逻辑中一般都有很多种类型的数据，例如 整形、字符型、集合、类 等，我们把它统称为 AO。

• 在**控制层（Controller）**与 **业务逻辑层（Service）**层之间抽象的复用对象模型，有时候极为贴近展示层，复用度不高

参考

• 浅谈 model, orm, dao 和 active record 的区别 (opens new window)
• DO、BO、DTO、VO、AO、PO、UID 名词意义 (opens new window)