比如创建用户,使用 userInsertDTO 绑定前端的参数并用 @Validated 校验,包含的参数:
如果是修改用户,一般会多一个用户的 id,使用 userUpdateDTO 接收前端参数,并用 @Validated 校验
或者 userUpdateDTO 只带一个 id,然后继承 userInsertDTO 的参数。并用 @Validated 校验
如果查询也用对象接收,条件查询 name,age 等参数都不是必须传,那我是否需要新建一个 userQueryDTO,并用 @Validated 校验。
这样子每个 PO,都要创建多个 DTO 。同样,如果我如果要返回数据给前端,也要创建很多个 VO 返回数据给前端。
这样会冗余吗?有每有更好的方法?
2
wangyanrui 2020-07-31 14:11:31 +08:00
如 1 楼所说,group = xxx 即可。
但是个人喜欢分成多个,即更新是更新的,修改是修改的~ |
3
Tokiomi 2020-07-31 14:30:21 +08:00
感觉分开比较好,但是懒
|
4
gdtdpt 2020-07-31 14:43:24 +08:00
分开好,大项目里牵一发动全身太难受了
|
5
Cbdy 2020-07-31 15:20:51 +08:00
这是合理做法的比较吧,你不想毕竟个加数据库字段,就要跟接口着变
|
6
kvkboy 2020-07-31 17:28:04 +08:00
个人观点哈,除非你这个 DTO 涉及到多个不同的业务对象你可以考虑分开,毕竟页面操作这种就很难说什么单一职责了,极端情况就是点一个按钮数据库被刷了一轮然后爆炸了。
如果是 1 对 1,你就该想一下,为什么不直接用 PO 而要麻烦的用一个 DTO 。 没道理你这个 InsertDTO 需要改动的地方,updateDTO 不会有变化 Validate 的话楼上的说了,可以分组 至于 VO 确实是硬伤,不过也有 GraphQL 用(但是我没用过,逃 |
8
luxinfl 2020-07-31 17:53:32 +08:00
我比较愿意分开多个 dto 来接参数,这样看起来清晰明了,要是几个接口的参数都放在一个 dto,就感觉很挤。
but 我现在就是放在一起的,因为懒 |
9
nozer 2020-07-31 17:55:57 +08:00
这是对前端最基本的尊重。
只取且取,我要的。 只给且给,你要的。 |
10
KuroNekoFan 2020-08-01 15:25:17 +08:00
minimal api 了解一下
|