这是一个创建于 1610 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如创建用户，使用 userInsertDTO 绑定前端的参数并用 @Validated 校验,包含的参数：
- name
- age
- birthday
- gender
- .....
如果是修改用户，一般会多一个用户的 id,使用 userUpdateDTO 接收前端参数，并用 @Validated 校验
- id
- name
- age
- birthday
- gender
- .....
或者 userUpdateDTO 只带一个 id,然后继承 userInsertDTO 的参数。并用 @Validated 校验
如果查询也用对象接收，条件查询 name,age 等参数都不是必须传，那我是否需要新建一个 userQueryDTO,并用 @Validated 校验。
- name
- age
这样子每个 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 了解一下
|
Select Language