查看“POJO JavaBean DO BO DTO VO PO SO”的源代码

=== DTO vs Request ===
{| class="wikitable"
|+
!DTO
!Request
|-
|Data Transfer Object，用于展示层与服务层之间的数据传输对象。
用来封装和接收 HTTP 请求中的参数；

用来封装和接收其他程序请求调用传递过来的参数；
|叫法不同，但应该和 DTO 起到一样的作用，请求的入参都通过 XXXRequest 来封装、
大概应该和 DTO 二选一。
|}





=== VO vs Response ===
{| class="wikitable"
!VO
!Response
|-
|
View Object，视图对象，用于展示层，把某个指定页面的展示数据封装起来。

用来封装和传递数据到前端（比如 JS 的 HTTP请求调用）；
|
叫法不同，但应该和 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 的方法才能实现；
{| class="wikitable"
! colspan="4" |AAAController
|-
! colspan="2" |BBBService
! colspan="2" |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

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