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

来自姬鸿昌的知识库
跳到导航 跳到搜索
第1行: 第1行:
 +
=== DTO vs Request ===
 +
{| class="wikitable"
 +
|+
 +
!DTO
 +
!Request
 +
|-
 +
|Data Transfer Object,用于展示层与服务层之间的数据传输对象。
 +
用来封装和接收 HTTP 请求中的参数;
 +
 +
用来封装和接收其他程序请求调用传递过来的参数;
 +
|叫法不同,但应该和 DTO 起到一样的作用,请求的入参都通过 XXXRequest 来封装、
 +
大概应该和 DTO 二选一。
 +
|}
 +
 +
 +
 +
 
=== VO vs Response ===
 
=== VO vs Response ===
 
{| class="wikitable"
 
{| class="wikitable"
第13行: 第30行:
 
大概应该和 VO 二选一。
 
大概应该和 VO 二选一。
 
|}
 
|}
 
 
 
Request
 
 
叫法不同,但应该和 DTO 起到一样的作用,请求的入参都通过 XXXRequest 来封装、
 
 
大概应该和 DTO 二选一。
 
=== DTO ===
 
Data Transfer Object,用于展示层与服务层之间的数据传输对象。
 
 
用来封装和接收 HTTP 请求中的参数;
 
 
用来封装和接收其他程序请求调用传递过来的参数;
 
 
  
 
=== BO ===
 
=== BO ===

2023年2月5日 (日) 04:42的版本

DTO vs Request

DTO Request
Data Transfer Object,用于展示层与服务层之间的数据传输对象。

用来封装和接收 HTTP 请求中的参数;

用来封装和接收其他程序请求调用传递过来的参数;

叫法不同,但应该和 DTO 起到一样的作用,请求的入参都通过 XXXRequest 来封装、

大概应该和 DTO 二选一。



VO vs Response

VO Response

View Object,视图对象,用于展示层,把某个指定页面的展示数据封装起来。

用来封装和传递数据到前端(比如 JS 的 HTTP请求调用);

叫法不同,但应该和 VO 起到一样的作用,返回结果都通过 XXXResponse 来封装

大概应该和 VO 二选一。

BO

Business Object,业务对象,把业务逻辑封装为一个对象。

用来在 Service 和 Service 之间封装和传递数据。


PO

Persistent Object,持久化对象,和持久层(如数据库)形成对应的映射关系

对应数据表的 Java 对象,属性列表应该和数据表中的字段完全一致。


DO

Domain Object,领域对象,从现实世界中抽象出来的有形或无形的业务实体。


Entity

实体对象由 Entity 承担




Service

是为了处理包含多个 POJO 对象(即对多个表的数据操作)时,进行事务的管理。

Service 层(其接口的实现类)被注入一个或多个 DAO 对象,以完成有意义的数据操作。

一般,Service 中的一个方法为一个事务,里面调用多个 DAO 对象的方法完成一个业务逻辑上的操作。


参考资料

https://www.bilibili.com/video/BV18L4y1F7PU

https://blog.csdn.net/weixin_43847283/article/details/121876570

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