比如一个用户 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 接收参数的地方可以再衍生一种,名字就换个没用过的,但我们这个项目只衍生一种就完全足够用了。