这是一个创建于 2093 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如创建用户，使用 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 年 7 月 31 日 如 1 楼所说，group = xxx 即可。 但是个人喜欢分成多个，即更新是更新的，修改是修改的~ |
 | 3 Tokiomi 2020 年 7 月 31 日 感觉分开比较好，但是懒 |
 | 4 gdtdpt 2020 年 7 月 31 日 分开好，大项目里牵一发动全身太难受了 |
 | 5 Cbdy 2020 年 7 月 31 日 这是合理做法的比较吧，你不想毕竟个加数据库字段，就要跟接口着变 |
 | 6 kvkboy 2020 年 7 月 31 日 个人观点哈，除非你这个 DTO 涉及到多个不同的业务对象你可以考虑分开，毕竟页面操作这种就很难说什么单一职责了，极端情况就是点一个按钮数据库被刷了一轮然后爆炸了。 如果是 1 对 1，你就该想一下，为什么不直接用 PO 而要麻烦的用一个 DTO 。 没道理你这个 InsertDTO 需要改动的地方，updateDTO 不会有变化 Validate 的话楼上的说了，可以分组 至于 VO 确实是硬伤，不过也有 GraphQL 用(但是我没用过，逃 |
 | 8 luxinfl 2020 年 7 月 31 日 我比较愿意分开多个 dto 来接参数，这样看起来清晰明了，要是几个接口的参数都放在一个 dto，就感觉很挤。 but 我现在就是放在一起的，因为懒 |
 | 9 nozer 2020 年 7 月 31 日 这是对前端最基本的尊重。 只取且取，我要的。 只给且给，你要的。 |
 | 10 KuroNekoFan 2020 年 8 月 1 日 minimal api 了解一下 |
Select Language