“POJO JavaBean DO BO DTO VO PO SO”的版本间的差异

2023年2月7日 (二) 22:17的版本

对比


	DTO	POJO	VO
名称	Data Transfer Object 数据传输对象	Plain Old Java Object 普通旧 Java 对象	Value Object 值对象
相同点
不同点
使用场景	封装 Web 请求传入的值


	SO	BO
名称	Service Object 服务对象	Business Object 业务对象
使用场景	作为若干个 BO （单个业务对象）的 facade 提供给 REST controller 调用	主要封装业务逻辑
不同点	供 REST controller 调用；业务逻辑代码少；直接和 DAO 打交道，包含事务处理；	供 SO 调用；业务逻辑代码多；不直接和DAO打交道，不包含事务处理
相同点	都包含业务逻辑代码的实现；
意义	事务处理；隐藏业务逻辑实现；	封装具体业务逻辑实现的细节

DTO

https://www.baeldung.com/java-pojo-javabeans-dto-vo#dto

https://www.baeldung.com/java-dto-pattern

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);
    }
}

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

Java 中，DTO 和 VO 的区别是什么？

DTO 更多的是一种用于在系统之间传输数据的对象。它通常仅包含数据，没有任何行为。DTO 的目的是保证数据的安全和效率，而不是表示数据的业务含义。

VO 是一种表示数据的对象，通常没有任何行为。它可以包含与业务相关的数据，并且在表示数据的同时也表示数据的业务含义。

以上参考 chatgpt 的回答。

道理上讲，DTO 转字符串之后响应给其他系统（HTTP 的前端调用或者其他跨系统的调用）可以是“[true, 1, "123", 2.13, {"key":"value"}]”，更主要的目的是传输数据，而不是说明传输数据的业务含义；

而 VO 应该能够说明数据的业务含义，比如“{price:12, name:"笔"}”，

但实际使用的时候 DTO 和 VO 似乎也非常相似，用起来基本是DTO 封装在 Controller 层接收的数据，VO 封装在 Controller 层响应的数据。

简而言之，DTO 的重点是数据传输，而 VO 的重点是表示数据和业务含义。它们都有各自的用途，可以根据业务需求进行选择使用。

多个表对应的一个 PO 是单独抽象出一个类好，还是在主要应用的一张表对应的 PO 里追加更多的属性用起来更好？

问题描述的是这种情况：

比如我有这么几张表，

student(id, name, age) 学生表

class(id, name) 班级表

teacher(id, name, age) 教师表

subject(id, name) 科目表

class_teacher_subject_rel(id, class_id, subject_id, teacher_id) 班级、教师、科目关系表，哪个班级、哪个科目、哪个老师教

score(id, stu_id, subject_id, score) 一次学生考试的分数表，学生id, 科目id，分数

然后现在需求是显示：

学生姓名	学生班级	科目	分数	教师名称
……	……	……	……	……

现在已经每个表有个 PO 了，为了映射关系型数据表查询结果到 Java 对象，是在某一个 PO 里扩展出其他字段好，还是单独再声明一个类出来好？

这个问题的答案取决于您的具体需求和设计目标。

一般而言，如果多个表涉及的数据是相互独立且易于分离的，

则将它们抽象为不同的 PO 类可能更容易维护和扩展。

但是，如果多个表中的数据存在密切关系，则在主 PO 类中包含所有关联数据可能更方便操作。

最终的决策应该取决于需要在代码中实现的业务逻辑和对模型的理解。

以上是 chatgpt 的回答，很有道理，所以其实是拆出来单独再创建一个类来保存还是在已有的 PO 中追加字段来保存取决于这些数据是否相互独立且易于分离。

上面这个业务中，查询结果跟所有表的关系都不远不近，也为了更方便后期扩展其他显示字段，单独再创建一个 PO 更好。

参考资料

优先级从高到底

https://www.baeldung.com/java-pojo-javabeans-dto-vo#:~:text=VO%2C%20also%20known%20as%20the,hold%20values%20such%20as%20java.

https://www.baeldung.com/java-dto-pattern

https://chat.openai.com/chat

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

https://www.jianshu.com/p/6c440b06cf6d