**
PO、VO、DAO、BO、DTO和POJO等术语被广泛应用于Java和其他编程语言中。尽管这些术语是非常常见的，但是很多程序员依然无法清楚地理解它们之间的区别和关系。本文将深入探讨这些术语的含义和用途，帮助程序员更好地理解它们之间的差异和联系。
**
对象关系图：
使用场景发布图：
一、PO
PO是“Persistent Object”的缩写，意为“持久化对象”。它通常用于表示数据库中的一条记录，即一组相关的数据。PO是由ORM（对象关系映射）框架生成或手动创建的Java对象，它们通常具有与数据库中的表相同的字段和数据类型。在Java开发中，PO常常被用作DAO（数据访问对象）层的数据模型，以及和数据库交互的对象。PO对象中的字段与数据库中的列相对应，每一行数据对应一个PO对象，PO对象中的字段值就是对应列的值。
package com.tigerhhzz.wuaimai.entity; /** * @author tigerhhzz * @date 2023/3/12 8:37 */ import com.baomidou.mybatisplus.annotation.FieldFill; import com.baomidou.mybatisplus.annotation.TableField; import lombok.Data; import java.io.Serializable; import java.time.LocalDateTime; /** * 员工实体 */ @Data public class Employee implements Serializable { private static final long serialVersionUID = 1L; private Long id; private String username; private String name; private String password; private String phone; private String sex; private String idNumber;//身份证号码 private Integer status; @TableField(fill = FieldFill.INSERT) //插入时填充字段 private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) //插入和更新时填充字段 private LocalDateTime updateTime; @TableField(fill = FieldFill.INSERT) private Long createUser; @TableField(fill = FieldFill.INSERT_UPDATE) private Long updateUser; }
二、VO
VO是“Value Object”的缩写，意为“值对象”。VO通常用于表示程序中的某个值或者一组相关的值，例如用户的姓名、年龄、地址等等。VO通常是一个不可变对象，也就是说，它的值在创建之后就不能再修改。在Java开发中，VO对象通常用于在不同层之间传递数据，例如在Controller层和Service层之间传递数据。VO对象和PO对象类似，但是它们的作用不同。VO通常是从PO对象中提取出来的一部分数据，用于展示和传递给前端界面。
三、DAO
DAO是“Data Access Object”的缩写，意为“数据访问对象”。DAO层是整个应用程序中与数据库交互的核心部分。DAO层负责将数据库中的数据转换成Java对象，并将Java对象的数据保存到数据库中。DAO层的主要作用是隔离上层业务逻辑和下层数据访问细节。在Java开发中，通常使用Hibernate等ORM框架来实现DAO层。DAO层的主要任务是实现数据的增删改查等基本操作，同时提供一些高级查询功能。
四、BO
BO是“Business Object”的缩写，意为“业务对象”。BO通常用于表示某个业务逻辑的实体或者模型。BO通常包含一些业务逻辑和方法，例如计算某些值、验证数据、调用其他服务等等。在Java开发中，BO对象通常由Service层或者Facade层来创建，并且它们通常包含一些业务逻辑的实现，以及对数据的操作。BO通常是针对具体的业务场景而设计的，它们是具有业务含义的实体。
五、DTO
DTO是“Data Transfer Object”的缩写，意为“数据传输对象”。DTO通常用于在不同层之间传输数据，例如在Controller层和Service层之间传输数据。DTO对象通常包含一些简单的数据结构，例如字符串、整数、布尔值等等。在Java开发中，DTO对象通常由Controller层或者Service层来创建，并且它们通常是不可变的。
package com.tigerhhzz.wuaimai.dto; import com.tigerhhzz.wuaimai.entity.Dish; import com.tigerhhzz.wuaimai.entity.DishFlavor; import lombok.Data; import java.util.ArrayList; import java.util.List; /** * @author tigerhhzz * @date 2023/3/15 15:03 */ @Data public class DishDto extends Dish { private List<DishFlavor> flavors = new ArrayList<>(); private String categoryName; private Integer copies; }
六、POJO
POJO是“Plain Old Java Object”的缩写，意为“简单的Java对象”。POJO通常指的是一个没有任何限制、继承或实现特定接口的普通Java对象。POJO对象通常是一种轻量级的Java对象，没有任何框架或者注解的依赖。在Java开发中，POJO对象通常用于表示简单的数据模型或者数据传输对象。
七、VO与DTO的区别
既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。
用一个例子来说明可能会比较容易理解：
例如Service层有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于Service层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。
理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中
- VO与DTO的应用
当需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，Service层的职责依然不应该与View层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）
即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐
以下场景需要优先考虑VO、DTO并存:
因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。
如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。
八、DTO与DO的区别
首先是概念上的区别，DTO是View层和Service层之间的数据传输对象（可以认为是两者之间的协议），而DO是对现实世界各种业务角色的抽象，这就引出了两者在数据上的区别，例如UserInfo和User（对于DTO和DO的命名规则，请参见笔者前面的一篇博文），对于一个getUser方法来说，本质上它永远不应该返回用户的密码，因此UserInfo至少比User少一个password的数据。而在领域驱动设计中，正如第一篇系列文章所说，DO不是简单的POJO，它具有领域业务逻辑。
- DTO与DO的应用
从上一节的例子中，细心的读者可能会发现问题：既然getUser方法返回的UserInfo不应该包含password，那么就不应该存在password这个属性定义，但如果同时有一个createUser的方法，传入的UserInfo需要包含用户的password，怎么办？在设计层面，View层向Service层传递的DTO与Service层返回给View层的DTO在概念上是不同的，但在实现层面，我们通常很少会这样做（定义两个UserInfo，甚至更多），因为这样做并不见得很明智，我们完全可以设计一个完全兼容的DTO，在服务层接收数据的时候，不该由View层设置的属性（如订单的总价应该由其单价、数量、折扣等决定），无论View层是否设置，Service层都一概忽略，而在Service层返回数据时，不该返回的数据（如用户密码），就不设置对应的属性。
对于DO来说，还有一点需要说明：为什么不在Service层中直接返回DO呢？这样可以省去DTO的编码和转换工作，原因如下:
两者在本质上的区别可能导致彼此并不一一对应，一个DTO可能对应多个DO，反之亦然，甚至两者存在多对多的关系。
DO具有一些不应该让View层知道的数据 DO具有业务方法，如果直接把DO传递给View层，View层的代码就可以绕过Service层直接调用它不应该访问的操作，对于基于AOP拦截Service层来进行访问控制的机制来说，这问题尤为突出，而在View层调用DO的业务方法也会因为事务的问题，让事务难以控制。
对于某些ORM框架（如hibernate）来说，通常会使用“延迟加载”技术，如果直接把DO暴露给View层，对于大部分情况，View层不在事务范围之内（Open session in view在大部分情况下不是一种值得推崇的设计），如果其尝试在Session关闭的情况下获取一个未加载的关联对象，会出现运行时异常（对于Hibernate来说，就是LazyInitiliaztionException）。
从设计层面来说，View层依赖于Service层，Service层依赖于领域层，如果把DO暴露出去，就会导致View层直接依赖于dao层，这虽然依然是单向依赖，但这种跨层依赖会导致不必要的耦合。
对于DTO来说，也有一点必须进行说明，就是DTO应该是一个“扁平的二维对象”
举个例子来说明：如果User会关联若干个其他实体（例如Address、Account、Region等），那么getUser()返回的UserInfo，是否就需要把其关联的对象的DTO都一并返回呢？如果这样的话，必然导致数据传输量的大增，对于分布式应用来说，由于涉及数据在网络上的传输、序列化和反序列化，这种设计更不可接受。如果getUser除了要返回User的基本信息外，还需要返回一个AccountId、AccountName、RegionId、RegionName，那么，请把这些属性定义到UserInfo中，把一个“立体”的对象树“压扁”成一个“扁平的二维对象”，笔者目前参与的项目是一个分布式系统，该系统不管三七二十一，把一个对象的所有关联对象都转换为相同结构的DTO对象树并返回，导致性能非常的慢。
九、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和Contacts两个DO数据合并到一张数据表中。反过来，如果一本图书Book，有一个属性是封面cover，但该属性是一副图片的二进制数据，而某些查询操作不希望把cover一并加载，从而减轻磁盘IO开销，同时假设ORM框架不支持属性级别的延迟加载，那么就需要考虑把cover独立到一张数据表中去，这样就形成一个DO对应对个PO的情况。
PO的某些属性值对于DO没有任何意义，这些属性值可能是为了解决某些持久化策略而存在的数据，例如为了实现“乐观锁”，PO存在一个version的属性，这个version对于DO来说是没有任何业务意义的，它不应该在DO中存在。同理，DO中也可能存在不需要持久化的属性。
- DO与PO的应用
由于ORM框架的功能非常强大而大行其道，而且JavaEE也推出了JPA规范，现在的业务应用开发，基本上不需要区分DO与PO，PO完全可以通过JPA，Hibernate Annotations/hbm隐藏在DO之中。虽然如此，但有些问题我们还必须注意：
对于DO中不需要持久化的属性，需要通过ORM显式的声明，如：在JPA中，可以利用@Transient声明。
对于PO中为了某种持久化策略而存在的属性，例如version，由于DO、PO合并了，必须在DO中声明，但由于这个属性对DO是没有任何业务意义的，需要让该属性对外隐藏起来，最常见的做法是把该属性的get/set方法私有化，甚至不提供get/set方法，但对于Hibernate来说，这需要特别注意，由于Hibernate从数据库读取数据转换为DO时，是利用反射机制先调用DO的空参数构造函数构造DO实例，然后再利用JavaBean的规范反射出set方法来为每个属性设值，如果不显式声明set方法，或把set方法设置为private，都会导致Hibernate无法初始化DO，从而出现运行时异常，可行的做法是把属性的set方法设置为protected。
对于一个DO对应多个PO，或者一个PO对应多个DO的场景，以及属性级别的延迟加载，Hibernate都提供了很好的支持，请参考Hibernate的相关资料。
七，总结
综上所述，PO、VO、DAO、BO、DTO和POJO都是Java开发中常见的术语和概念，它们分别代表不同的含义和用途。其中，PO用于表示数据库中的数据模型，VO用于表示传递给前端的数据模型，DAO用于访问数据库，BO用于表示业务逻辑实体，DTO用于在不同层之间传输数据，POJO用于表示简单的Java对象。在实际的开发中，程序员需要根据不同的场景选择适当的对象类型，并且清楚地理解它们之间的区别和联系。
