这是一个创建于 1133 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如数据库有个表，对应 java 模型是：
public class User { @Comment("用户 id") @Column(length = 36) private String id; @Comment("用户名") private String userame; @Comment("昵称") private String nickname; @Comment("登录密码") private String password; @Comment("密码过期时间") private Date passwordExireTime; @Comment("0: 新用户 1: 正常使用 2:停止使用") private Integer status; @Comment("最近登录时间") private Date loginTime; @Comment("连续登录错误次数") private Integer loginErrorCount; @Comment("创建时间") private Date createdAt; @Comment("所属组") private String userGroupId; } 举个例子，现在有新增、删除、更新接口，每个接口传的参数不一样并且校验参数的逻辑也不一样，现在我的处理是生成三个参数对象: InsertUserForm 、DeleteUserForm 、UpdateUserForm ，然后用不同的校验逻辑，这三个对象都会返回不同的参数，需要新建三个对象存储返回参数 InsertUserVO, DeleteUserVO, UpdateUserVO ，想问一下实际怎么处理这些情况的？
 | 1 gwkoooo 2022-09-09 09:33:36 +08:00 新增和编辑可以用 @Validate 的分组校验，返回的话就分开新建，也可以请求参数抽取一个 BaseForm ，返回参数收取一个 BaseVO 继承一下 |
 | 2 KingOfUSA 2022-09-09 09:33:44 +08:00 1. 对于你这种通过对象入参的方式暂时还没有想到更好的处理方式。我个人更喜欢普通类型的入参，然后定义一些常用的规则(比如类型、长度、是否避免等)，在 controller 层对于参数加上不同的规则。 2. 返回参数的问题，可以使用我写的这个库 https://github.com/ksprider/Surgical ，在 controller 层通过注解的方式来决定返回不同的属性，避免了 vo1 vo2 vo3...难以复用的情况 |
 | 5 7911364440 2022-09-09 09:39:01 +08:00 |
 | 6 Edsie 2022-09-09 09:56:09 +08:00 定义一个领域层面的 User ，（你上面的 User 是属于 Entity 的） ``` public class Use { private String username; private String nickname; private String password; } ``` create,update,delete 主题都是它，校验逻辑通过分组校验分开 |
 | 7 git00ll 2022-09-09 10:48:06 +08:00 我觉得建三个没问题，区分出来比较清晰。1f 那样做 会在增加复杂性。 并且这种接口写完了一般不会改 |
 | 8 xiao109 2022-09-09 11:20:36 +08:00 Map 打天下 |
 | 9 KevinBlandy 2022-09-09 11:22:17 +08:00 Validate 那 group 真不建议用，用着用着能给自己整糊涂了。不同业务接口，创建不同对象吧还是。必要的时候可以用 MapStruct 之类的工具转换。 |
 | 10 frank1256 2022-09-09 11:48:27 +08:00 MapStruct |
 | 11 egfegdfr 2022-09-09 13:45:53 +08:00 entity 类，能满足的情况下，就直接用 entity ，entity 不够的话，增加 vo 类。能复用的情况下，尽量复用。如果每一个接口都严格按照你这种方式来，会照成大量的重复性的代码。不利于维护 |
 | 12 kqq19930511 OP @xiao109 可维护性太差了 |
| 13 kqq19930511 OP @KevinBlandy 是的，现在啊就是用 mapstruct 转换的 |
| 14 kqq19930511 OP @Edsie 需要生成 swagger 文档，这种设计不行吧 |
 | 15 Leviathann 2022-09-09 13:58:24 +08:00 就分开啊 不一样的东西不要放一起 或者抽一个 UserCommons 之类的接口把共性提取出来 |
| 16 kqq19930511 OP @7911364440 怎么配合 swagger 生成文档呢？ |
| 17 7911364440 2022-09-09 14:21:08 +08:00 @kqq19930511 可以在字段注释上加一些特殊说明，比如新增时必填，修改时必填之类的 |
 | 18 Rache1 2022-09-09 17:17:04 +08:00 挤在一起就违反单一原则了 |
 | 19 likeme 2022-09-09 17:39:27 +08:00 我也是按照你这个思路开发的。这样挺好啊，没有耦合，只不过代码冗余比较多，这点冗余没什么吧。。。起码可以让代码看的清晰明了。 |
 | 20 zhuweiyou 2022-09-09 17:40:59 +08:00 Map 一把梭 |
 | 21 28Sv0ngQfIE7Yloe 2022-09-10 00:45:49 +08:00 分开降低心智负担，简单的业务倒是可以用 Groups ，等到你针对这个 Entity 的业务变多了，那些个 b 注解能看的吐血 |
 | 22 liangkang1436 2022-09-10 10:38:48 +08:00 via Android 分组校验的最大的好处是集中校验逻辑，集中错误信息，在应用的多个层面对同一个实体进行校验的时候去除重复代码，但是坏处就是当分组较多的时候，看起来会有点乱（虽然这在我看来不是缺点），跟 swagger 的适配应该也不是难事，毕竟 beanvalidation 都发展这些年了，不可能不兼容。 |
| 23 liangkang1436 2022-09-10 10:41:18 +08:00 via Android 强烈不建议用 map 传参，代码的可读性和可维护性都会特别差，尽量使用类型参数，用面向对象的思想封装参数，将来你看自己的代码，到处都是 map ，不调试不根本不知道里面到底都是啥内容 |
Select Language