Java中常见的对象类型简述(DO、BO、DTO、VO、AO、PO)

概念及理解
这些概念用于描述对象的类型；由于java是面向对象的语言；程序的世界就是各个对象之间的“交互”；在交互的工程中会存在多个层次，每个层次中所拥有（关注）的内容都是不一样的；

PO(Persistant Object) 持久对象
用于表示数据库中的一条记录映射成的 java 对象。PO 仅仅用于表示数据，没有任何数据操作。通常遵守 Java Bean 的规范，拥有 getter/setter 方法。

可以理解是一个PO就是数据库中的一条记录；可以理解某个事务依赖的原始数据；好处是可以将一条记录最为一个对象处理，可以方便转化为其他对象

通常对应数据模型 ( 数据库 ), 本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的 java 对象。最简单的 PO 就是对应数据库中某个表中的一条记录，多个记录可以用 PO 的集合。 PO 中应该不包含任何对数据库的操作。

BO(Business Object) 业务对象
封装对象、复杂对象，里面可能包含多个类
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。

用于表示一个业务对象。BO 包括了业务逻辑，常常封装了对 DAO、RPC 等的调用，可以进行 PO 与 VO/DTO 之间的转换。BO 通常位于业务层，要区别于直接对外提供服务的服务层：BO 提供了基本业务单元的基本业务操作，在设计上属于被服务层业务流程调用的对象，一个业务流程可能需要调用多个 BO 来完成。

比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。

VO(Value Object) 表现对象
前端界面展示；value object值对象；ViewObject表现层对象；主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值；对于Android而言即是activity或view中的数据元素。

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

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

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

DAO(Data access object) 数据访问对象
这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.，主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO；

用于表示一个数据访问对象。使用 DAO 访问数据库，包括插入、更新、删除、查询等操作，与 PO 一起使用。DAO 一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。

POJO(Plain ordinary java object) 简单java对象
一个POJO持久化以后就是PO；直接用它传递、传递过程中就是DTO；直接用来对应表示层就是VO。

举个例子：
事情：统计研发部门中的季度绩效（暂定以工程师填写的为准，当然实际上大部分不是）
过程：CTO发布统计绩效请求（附带要求：每个人对应的绩效等级）->各个组（也可以是子部门）负责人发布统计绩效请求（每个对应的绩效等级，并将绩效分为了3个方面）->每位开发工程师统计自己绩效（自身各个方面）；
可以从例子中看到：每个责任人要求都不同；
对于CTO，他需要知道的是该季度所用员工的绩效等级；这里可以认为VO：员工姓名、绩效等级；
开发工程师：需将本人这个季度的各个方面的表现都列出来：员工姓名、绩效等级、Ａ方面表现内容及等级、B方面表现内容及等级、C方面表现内容及等级、D方面表现内容及等级、E方面表现内容及等级、F方面表现内容及等级、E方面表现内容及等级；此处可认为是PO：员工姓名、绩效等级、A方面表现内容、A方面等级….E方面表现内容、E方面等级；
然后开发工程师将员工姓名、绩效等级、Ａ方面表现内容及等级、B方面表现内容及等级、C方面表现内容及等级内容传递给小组负责人；此处传递的对象就是DTO
小组负责人：从开发工程师中获取到数据后，经过评定，然后得出员工姓名、绩效等级、原因；此处的评定，可以理解为ＢＯ；

 

 

分层领域模型规约:

 DO(Data Object):此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。

 DTO(Data Transfer Object):数据传输对象，Service 或 Manager 向外传输的对象。

 BO(Business Object):业务对象，由 Service 层输出的封装业务逻辑的对象。

  AO(ApplicationObject):应用对象，在Web层与Service层之间抽象的复用对象模型， 极为贴近展示层，复用度不高。

  VO(View Object):显示层对象，通常是 Web 向模板渲染引擎层传输的对象。

 Query:数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止

使用 Map 类来传输。

最难理解的是BO，大致这么理解：

BO这个对象可以包括一个或多个其它的对象。

比如一个简历，有教育经历、工作经历、社会关系等等。

我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。

建立一个对应简历的BO对象处理简历，每个BO包含这些PO。这样处理业务逻辑时，我们就可以针对BO去处理。

------------------------------------------------------------------------------------------------------------------------------------------------------

大致的示例代码：

Controller层

public List<UserVO> getUsers(UserQuery userQuery);

此层常见的转换为：DTO转VO

Service层、Manager层

// 普通的service层接口

 List<UserDTO> getUsers(UserQuery userQuery);

然后在Service内部使用UserBO封装中间所需的逻辑对象

// 来自前端的请求

 List<UserDTO> getUsers(UserAO userAo);

此层常见的转换为：DO转BO、BO转DTO

DAO层

List<UserDO> getUsers(UserQuery userQuery);

------------------------------------------------------------------------------------------------------------------------------------------------------

三、各种对象该怎么转换？
 

那么这里又涉及到另外一个问题，各种对象转换该怎么办呢？

常见的写一个转换方法，然后手动调用get/set方法，属性太多非常痛苦，容易遗漏或者重复，而且效率非常低下。

 

推荐两种方式：

（1）一种是通过IDEA插件实现快速自动生成转换代码.

如Generate All setters插件，参见https://blog.csdn.net/w605283073/article/details/89163627

定义好参数和返回值，使用快捷方式可以轻松生成转换的代码。

（2）一种是通过第三方转换库来转换。

Apache org.apache.commons.beanutils.PropertyUtils.copyProperties
Apache org.apache.commons.beanutils.BeanUtils.copyProperties
Spring org.springframework.beans.BeanUtils.copyProperties
Cglib BeanCopier
Dozer
orika

对应的maven依赖（已经给出了maven地址，建议用最新版本）

<!-- https://mvnrepository.com/artifact/commons-beanutils/commons-beanutils -->
<dependency>
    <groupId>commons-beanutils</groupId>
    <artifactId>commons-beanutils</artifactId>
    <version>1.9.3</version>
</dependency>
 
 
<!-- https://mvnrepository.com/artifact/org.springframework/spring-beans -->
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-beans</artifactId>
    <version>5.1.6.RELEASE</version>
</dependency>
 
 
<!-- https://mvnrepository.com/artifact/cglib/cglib -->
<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.2.11</version>
</dependency>
 
 
<!-- https://mvnrepository.com/artifact/net.sf.dozer/dozer -->
<dependency>
    <groupId>net.sf.dozer</groupId>
    <artifactId>dozer</artifactId>
    <version>5.5.1</version>
</dependency>
 
 
<!-- https://mvnrepository.com/artifact/ma.glasnost.orika/orika-core -->
<dependency>
    <groupId>ma.glasnost.orika</groupId>
    <artifactId>orika-core</artifactId>
    <version>1.5.4</version>
</dependency>

 

从效率来讲，读过其他文章，综合而言cglib应该最高，其次是orika。

因为

cglib用的是asm，直接操作内存对象的字节码增强技术。

orika用的是javassist, 通过动态字节码生成实现对象转换。

 

具体用法在这里就不介绍了，需要的话去官网看看文档也可以去github看下demo。

我的看法：

第二种代码实现对象转换简洁并且功能强大，但是我个人非常推崇第一种写转换方法的方式，因为这种方式对象属性改变可以直观反映到代码上，也可以避免因为粗心和增删属性等出现的莫名其妙的错误。