VO，BO，PO，DO，DTO 确实搞不明白？

Z时代
2024-03-06
分类：IT

比如一个用户 User 模型

如果是 Controller 层里面注册接收前端数据，这个时候是不是叫 @RequestBody UserDto userDto，如果是后端返回给前端的是不是叫 UserVo userVo；

那 service 层的是不是叫 UserBo

然后就是与数据库对用的就是 UserDo

让用户注册，是不是接收到 UserDto 转成 UserBo 转成 UserDo 入库

获取是不是 UserDo 转成 UserBo 转成 UserVo 给前端

PO 又是啥时候用？

回答：

这些东西只是大家约定俗成的，没有明确的标注，每个公司可自定义标准,根据需求自己确定,没必要生搬硬套，甚至全部都用。
习惯把与数据库一一对应的实体称为entity,如果你不在乎数据的私密性，完全可以在service,controller,以及controller接收的参数全部使用这个entity，而不用其他任何东西。但一般我们都会创建一个与此类似的类，删减一些私密字段（比如用户密码），或增加一些数据库不存在的字段(比如连表查询结果包含多个表的字段)，如何给这个类命名，这个就是问题所说的dto,vo等类的来源。
无论是Dto,vo,bo.do,po 都是entity衍生出来的，最终入库都会合并成entity,一般我只使用一个，名字随意啦，叫entity旺财都可以，但为了一目了然，建议还是使用Vo(value object)或dto(data transfer object)，为了细化，在controller 接收参数的地方可以再衍生一种，名字就换个没用过的，但我们这个项目只衍生一种就完全足够用了。

回答：

阿里开发命名规范，Dto 传输对象 Vo 试图对象 Do数据对象都是英文缩写,相关数据可以去githuba上进行查找

回答：

Naming conventions for Domain models
1) Data Object: DO, where is the table name.
2) Data Transfer Object: DTO, where is a domain-related name.
3) Value Object: VO, where is a website name in most cases.
4) POJO generally point to DO/DTO/BO/VO but cannot be used in naming as *POJO.

VO，BO，PO，DO，DTO 确实搞不明白？

回答：

回答：

回答：

相关文档

其他人也看了：