比如数据库有个表,对应 java 模型是:
public class User {
@Comment("用户 id")
@Column(length = 36)
private String id;
@Comment("用户名")
private String username;
@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 User { 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 ,不调试不根本不知道里面到底都是啥内容
|