先来一张图，有一个直观地感受：
概念介绍
-
VO（View Object）视图对象
用于展示层（和控制层Controller共同属于表现层），它的作用是把某个指定页面（或组件）的所有数据封装起来。说白了，就是在
service层返回给前端页面展示的数据信息，也就是平时看到的网页列表中展示的数据信息 -
DTO（Data Transfer Object）数据传输对象
展示层与服务层之间的数据传输对象，它是一个简单的
POJO类，通常只包含属性和属性的get/set方法，没有业务逻辑，主要用于数据传输。DTO的设计思想是为了简化数据传输的过程，减少不必要的数据暴露和网络传输的开销。比如一张表有 100 个字段，那么对应的
PO类 就有 100 个属性。但是界面上只要显示 10 个字段，客户端用 WEB service 来获取数据，没有必要把整个 PO 对象传递到客户端，这时我们就可以用只有这 10 个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VODTO通常用于以下场景：
（1）在远程调用中，将数据从服务提供者传输到服务消费者。
（2）在前端和后端之间传输数据，如最开始的架构图，DTO横跨两层，在Controller层和Service层之间使用。通常情况下，DTO在Controller层用于接收和响应客户端请求，在接收客户端请求时，Controller可以使用DTO对象来解析请求参数，并将数据传递给Service层进行业务处理，在响应客户端请求时，Controller可以将Service层返回的数据转换为DTO对象，并以适当的格式返回给客户端
（3）在分布式系统中，将数据从一个节点传输到另一个节点。
（4）在微服务架构中，将数据从一个微服务传输到另一个微服务. -
BO（Business Object）业务对象
BO就是PO的组合，数据库里面多个PO对象构成的相对复杂的对象，业务对象BO主要作用是把业务逻辑封装为一个对象（包括一个或多个其它的对象）比如
PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象。再比如一个简历，有教育经历、工作经历、社会关系等等，可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO，然后建立一个对应简历的BO对象处理简历，每个BO包含这些PO，这样处理业务逻辑时，就可以针对BO去处理BO是一个业务对象，一类业务就会对应一个BO，BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法BO也是横跨两层，原因是现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成很多情况下为了追求查询的效率，框架跳过
PO直接生成BO的情况非常普遍，PO只是用来增删改使用，通常需要将BO转化成PO，才能进行数据的持久化，反之，从数据库中得到的PO，需要转化成BO才能在业务层使用 -
PO（Persistant Object）持久对象
PO类包括属性、构造函数、get和set方法，PO类是一个模板或定义，描述了数据库记录的结构和属性，而PO对象是基于PO类实例化的具体记录对象。PO对象是PO类的实例化对象，它是在运行时创建的具体记录，PO对象可以操作和访问数据库中的数据。每个PO对象代表数据库中的一条记录，它的属性值对应数据库表中的字段值简单说一个
PO对象就是数据库中的一条记录，PO类对应着数据库中的一个表，定义的是PO类，PO对象是运行时创建出来的一条记录（包含多个属性） -
DO（Domain Object）领域对象
从现实世界中抽象出来的有形或无形的业务实体，目前有两种概念：
（1）一个是阿里巴巴的开发手册中的定义
DO（ Data Object） =PO（2）另一个是在DDD（Domain-Driven Design）领域驱动设计中
DO（Domain Object） =BO（这种应该多一点）
概念区别
-
VO与DTO的区别
对于绝大部分的应用场景来说，
DTO和VO的属性值基本是一致的，但是DTO代表服务层（service）需要接收的数据和返回的数据，而VO代表展示层需要显示的数据如果客户端不止一个（PC端、手机端等），或者客户端需要定制，则需要把
VO和DTO区分开来，否则可以只用一个DTO -
DO（BO）与PO的区别
BO对象关注业务逻辑和行为，它们封装了业务规则和操作，用于实现业务逻辑的控制和处理。PO对象关注数据存储和持久化，它们提供对数据库记录的操作和访问接口BO对象通常是可变的，因为业务逻辑需要对其进行修改和操作。而PO对象通常是不可变的，因为它们代表了数据库中的静态记录，应保持与数据库的一致性
