JAVA中PO、VO、BO、POJO、DAO、DTO、TO的理解

【强制】类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
正例：ForceCode / UserDO / HtmlDTO / XmlService / TcpUdpDeal / TaPromotion
反例：forcecode / UserDo / HTMLDto / XMLService / TCPUDPDeal / TAPromotion

【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。(四) OOP 规约
【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。
反例：：POJO 类的 createTime 默认值为 new Date()，但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。

2.简单类：包括 DO/DTO/BO/VO 等

DTO（Data Transfer Object）数据传输对象

用于不同应用的数据传输

DAO （Data Access Object）数据访问对象

是一个数据访问接口，主要是与数据库交互。主要用来封装对数据的访问，注意，是对数据的访问，不是对数据库的访问。

DO（Data Object）

阿里巴巴专指数据库表一一对应的 POJO 类。

DO （Domain Object）领域对象

领域对象 DO 是从现实世界中抽象出来的有形或无形的业务实体。在与数据有关的操作中数据存在数据库使用DAO访问被取出来时，一般会将这些数据规范化的定义成类，而这个类就是DO，用来接收数据库对应的实体，它是一种抽象化的数据状态，介于数据库与业务逻辑之间。

一般在业务逻辑层（Service）对数据库（SQL）的访问时接收数据使用。

xxxDO，xxx即为数据表名

另外：DO与Entity概念上浅显的相同，他们在实际应用中是一个东西。稍微的不同点就是DO是与数据库存在着某种映射关系的Entity，总的来说DO是Entity的一种。

VO（View Object）视图模型
用于和前端的交互，接受前端回传的数据，返回给前端，做视图展示

xxxVO，xxx一般为网页名称。

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

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

BO（ Business Object）业务对象
业务对象(Business Object，BO)是对数据进行检索和处理的组件。主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。形象描述为一个对象的形为和动作，当然也有涉及到基它对象的一些形为和动作。

一般用在包含业务功能模块的具体实例上，比如我们写了一个Controller、一个Service、一个DAO、一个工具类等等这一系列实例组合后能实现一些功能，这些一系列实例组合为一个组件，这个组件就是BO。

POJO（ Plain Ordinary Java Object）纯普通Java对象
POJO 专指只有 setter/getter/toString 的DTO。总的来说POJO包含DO、DTO、BO、VO，这些本质上都是一个简单的java对象，实际就是普通JavaBeans，是为了避免和EJB混淆所创造的简称

PO（Persistent Object）持久化对象
与数据库的属性和字段一一对应

Entity（应用程序域中的一个概念）实体
Entity（应用程序域中的一个概念）实体

Eitity是一个未被持久化的对象，它是一个类，从现实抽象到代码的一个类。

Model （概念实体模型）实体类和模型
Model是计算机程序设计中有两个概念：一个是三层架构中的实体类，另一个是MVC架构中的模型。

3.与MVC三层架构的关系

在“三层架构”中，为了面向对象编程，将各层传递的数据封装成实体类，便于数据传递和提高可读性。

在MVC（模型Model-视图View-控制器Controller）模式中，Model代表模型，是业务流程/状态的处理以及业务规则的制定，接受视图请求的数据，并返回最终的处理结果。View代表视图，用来解析Model带来的数据模型。业务模型的设计可以说是MVC最主要的核心。

通常意义上的三层架构就是将整个业务应用划分为：表现层、业务逻辑层、数据访问层。区分层次的目的即为了“高内聚，低耦合”的思想。

表现层（web）：用于接收用户提交请求及响应处理。
业务逻辑层（service）：对数据业务逻辑处理。
数据访问层（dao）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等

4.总结

PO持久对象：与数据库的属性和字段一一对应

DO领域对象：基于实体和事件的业务对象，在构建复杂的系统的时候，采用领域驱动的设计思想，可以降低开发的复杂度

DTO数据传输对象：用于不同应用的数据传输，分布式，微服务的名称

VO值对象：用于和前端的交互，接受前端回传的数据，返回给前端，做视图展示

BO业务对象：封装多个PO，在Service层处理各种业务

4.1.为什么要分这些对象

因为在不同的业务中，同一个对象的作用是不同的，比如添加用户需要密码，但是查看信息，就只能返回部分的信息，甚至敏感信息要特殊处理，虽然有注解可以帮助我们解决这些问题，但是，处理的并不全面，而且不能视情况处理，反而增加了业务的复杂度
减少业务直接的耦合，当我们的需求有变动的时候，我改变字段的内容，不会影响到其他的业务的正常执行
让程序员做到见名知意，我们在命名对象的时候，就要以XXXDO，xxxVO命名，这样其他程序员在维护我们代码的时候，也知道应该怎么处理这些信息

4.2.什么时候需要定义这么多O

项目中真的有必要定义VO，BO，PO，DO，DTO吗？按照理论上来讲

如果项目比较小，是一个简单的MVC项目，又是单兵作战，我不建议使用VO，BO，PO，DO，DTO，直接用POJO负责各个层来传输就好，因为这种项目的“目的地”是快速完成。
而我们更多的时候，是持续迭代的团队协作项目，这个时候我们就建议用VO，BO，PO，DO，DTO，而且团队内要达成共识，形成一个标准规范。

4.3.实体对象之间如何转换？

BeanUtils.copyProperties(srcVo,destDto);
mapper.map(srcVo,DestDto.class);

参考资料

参考深入理解 DAO的概念_旷野历程的博客

概念POJO晓风残月淡的博客

《阿里Java 开发手册黄山版》

vo、dto、bo、do、po的概念理解Albertliuc的博客