POJO JavaBean DO BO DTO VO PO SO
DTO
https://www.baeldung.com/java-pojo-javabeans-dto-vo#dto
Data Transfer Object，也称为数据传输对象，封装值以在进程或网络之间传输数据。
这有助于减少调用的方法的数量。通过在单个调用中包含多个参数或值，我们减少了远程操作中的网络开销。
这种模式的另一个优点是序列化逻辑的封装。它允许程序以特定格式存储和传输数据。
DTO 没有任何明确的行为。它基本上有助于通过将域模型与表示层解耦来使代码松散耦合。
如何使用 DTO ？
https://www.baeldung.com/java-pojo-javabeans-dto-vo#2-how-to-use-dto
DTO 具有扁平结构，没有任何业务逻辑。它们使用与 POJO 相同的格式。
DTO 仅包含与序列化或解析相关的存储、访问器和方法。
DTO 基本上映射到域模型，从而将数据发送到方法或服务器。
让我们创建 EmployeeDTO，它将创建员工所需的所有信息组织起来。我们将在优化与 API 交互的单个请求中将此数据发送到服务器：
public class EmployeeDTO {
private String firstName;
private String lastName;
private LocalDate startDate;
// standard getters and setters
}
上面的 DTO 与不同的服务交互并处理数据流。这种 DTO 模式可以在任何服务中使用，没有任何框架限制。
同样功能，有的公司代码实现命名叫 XXXRequest。
VO
https://www.baeldung.com/java-pojo-javabeans-dto-vo#vo
Value Object，也称为值对象，是一种特殊类型的对象，可以保存 java.lang.Integer 和 java.lang.Long 等值。
VO 应该总是覆盖 equals() 和 hashCode() 方法。VO 一般会封装数字、日期、字符串等小对象。它们遵循语义，即它们直接更改对象的值并传递副本而不是引用。
使值对象不可变是一种很好的做法。值的更改仅通过创建新对象发生，而不是通过更新旧对象本身的值发生。
这有助于理解两个创建相等的值对象应该保持相等的隐式约定。
示例定义 EmployeeVO 并且覆盖 equals() 和 hashCode() 方法：
public final class EmployeeVO {
private final String firstName;
private final String lastName;
private final LocalDate startDate;
public EmployeeVO(String firstName, String lastName, LocalDate startDate) {
this.firstName = firstName;
this.lastName = lastName;
this.startDate = startDate;
}
// Getters
@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (obj == null || getClass() != obj.getClass()) return false;
EmployeeVO emp = (EmployeeVO) obj;
return Objects.equals(firstName, emp.firstName)
&& Objects.equals(lastName, emp.lastName)
&& Objects.equals(startDate, emp.startDate);
}
@Override
public int hashCode() {
return Objects.hash(firstName, lastName, startDate);
}
}
Response
叫法不同，但应该和 VO 起到一样的作用，返回结果都通过 XXXResponse 来封装
大概应该和 VO 二选一。
PO
Persistent Object，持久化对象，和持久层（如数据库）形成对应的映射关系
对应数据表的 Java 对象，属性列表应该和数据表中的字段完全一致。
DO
Domain Object，领域对象，从现实世界中抽象出来的有形或无形的业务实体。
Entity
实体对象由 Entity 承担
SO
Service Object，服务对象。
在典型的分层应用程序体系结构中，有3个不同的层：
- 表示/视图层
- 服务/业务层
- 数据访问/持久层
表示或视图层由负责传入请求接口的所有“Web”或“Rest”类组成；
顾名思义，数据访问或持久层只是一个用于封装数据相关逻辑的层，DAO 和 DTO 模式实际上都位于这一层；
最后，服务层是负责核心业务逻辑的层，因此这是服务对象所在的层。
服务对象（SO）只是一个用于封装业务逻辑的对象。
这个 SO 的一个常见示例是服务类。比如：ItemService
是为了处理包含多个 POJO 对象（即对多个表的数据操作）时，进行事务的管理。
Service 层（其接口的实现类）被注入一个或多个 DAO 对象，以完成有意义的数据操作。
一般，Service 中的一个方法为一个事务，里面调用多个 DAO 对象的方法完成一个业务逻辑上的操作。
BO
Business Object，业务对象。
它是一个包含业务逻辑代码的对象。
简而言之，BO 几乎就是一个 SO。
这只是 enterprise Java 世界中的术语问题。
但是，一些开发人员还在其他地方使用 BO。
你可能已经看到包含大量业务逻辑但实际上并没有被归类为 'Service Object'（服务对象）的类，因为它没有向调用 Web 层的 REST 控制器暴露‘Service’（服务）层约定。
这是 BO 与 SO 的不同之处。
当可以将业务逻辑代码放在 SO 中以有效地将 SO 转换为 BO 时，可以考虑将业务逻辑代码抽象到它自己的类—— BO 中。
让 SO 本身成为许多单独业务对象的“facade”（外观）或“orchestrator”（协调器）。
BO 和 SO 是 N:1的关系；
SO 中的一个方法可能需要调用多个 BO 的方法才能实现；
| AAAController | |||
|---|---|---|---|
| BBBService | CCCService | ||
| DDDBO | EEEBO | FFFBO | GGGBO |
参考资料
优先级从高到底
https://blog.devgenius.io/dao-dto-po-so-bo-vo-wtf-6673c9dd5437
https://www.bilibili.com/video/BV18L4y1F7PU
https://blog.csdn.net/weixin_43847283/article/details/121876570