程序员写接口参数校验,总是太多if else?一招让你避免体力活

对于写Java的程序员来说,不管是写单纯的接口、还是页面后台一把梭,后端参数校验的功能都是整个代码不可或缺的一部分,它可以从系统入口过滤掉一些不合法的数据,以确保我们的系统稳定。

还记得我刚入行Java写后端那会儿,因为刚从Android端转后端开发,对对端开发还不是很熟悉。有天我们架构师老大给了我一个需求、要写一个接口给客户端调用,功能其实挺简单:就是根据客户端传过来的一些参数去数据库查数据,再返回给客户端。

我虽然作为一个后端萌新,但毕竟写代码的底子还在啊!很快我就完成了,自己测试一下完美通过,立刻提交代码、并主动叫我们老大Code review,我心里还指着我们老大能夸我一顿、说我写得真快呢!

没想到我们老大只看了一眼就把我提交的代码打回来了,我记得当时我的代码差不多是这样写的:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

我自问写的代码没问题,就找老大问他我的代码没问题怎么给我打回来了?只见老大一脸无奈地看着我说:功能是没问题,就是写的太丑陋了点。好吧,我承认代码写的是长了点、乱了点,可那是因为接口参数太多,不得一个个校验一下吗?

说到这里,老大微微一笑说:来,教你一招。只见老大手指上下翻飞,三两下就我的校验参数地代码全删完了,重构完地代码瞬间清爽了许多:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

老大得意的对我说:看起来不错吧?不要你晚上加个班熟悉一下Spring Validation机制吧?宝宝心里苦啊!

下面我们就一起来看看Spring Validation怎么使用吧。

首先添加POM依赖

新建一个Spring Boot项目,并在pom.xml文件添加依赖:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

需要特别注意的一点是:如果我们项目中引入了 spring-boot-starter-web 依赖,那么它会自动依赖 spring-boot-starter-validation ,无需我们再手动添加依赖,防止出现一些版本兼容的问题。

添加约束注解

在接收参数的 UserReq 实体类对应的属性上加上约束注解:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

注意点:

  • 每个约束注解都有一个 message 元素,用于校验失败时的提示信息
  • 一个属性可以添加多个约束注解,所有注解是与的关系,必须全部验证通过
  • 可以使用正则表达式校验参数

眼尖的同学可能会发现上面代码中用到的一些约束注解一些是引用自 javax.validation.constraints 包下,还有一些引用自 org.hibernate.validator.constraints 包下,这是怎么一回事呢?

说到这里,不得不提一下 JSR-303 ,JSR-303是JAVA EE(现改名为:Jakarta EE)中的一项子规范,叫 Bean Validation ,它定义了一些实体和方法验证的约束和接口规范,而 Hibernate Validator 对Bean Validation规范中所有内置约束注解都提供了实现,并且还添加了一些额外的约束注解。

Bean Validation中内置的约束注解:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

Hibernate Validator中添加的约束注解:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

值得一提的是:在 Hibernate Validator 中额外添加的一些优秀的约束注解比如 @Email@NotEmpty@NotBlank 已经被吸收到 Bean Validation 标准约束注解中,所有我们在代码中Import时应尽量使用 javax.validation.constraints 包下的约束注解。

怎么使用呢?

接收参数的实体类我们已经改造好了,但是还不能实现校验的功能,还需要对Controller进行改造:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

  • 在接收方法的参数前面加上 @Validated 注解,当然也可以加 @Valid 注解
  • 想要获取参数校验的结果,则需要进行校验的参数后面紧跟一个 BingingResult 类型的参数,用来绑定校验结果

关于第一点, @Validated 注解由Spring框架提供,可以说是对 JSR-303 规范标准注解@Valid的封装,可以提供额外的例如分组校验的功能。实际上任何以" Valid "开头的注解都可以实现同样的效果(至于原因有机会专门写一篇讲一下,感兴趣的可以关注一下)

至于第二点,为什么校验结果会自动绑定到后面紧跟的 BingingResult 对象,这里面涉及到Spring DataBinder数据绑定相关的知识(以后会专门讲解,感兴趣的可以关注一下),现在我们只需要知道这样写就行。

请求测试

现在我们使用Postman工具来请求我们的接口:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

然后我们打上断点来调试一下 bindingResult 对象:

可以看到 bindingResult 对象成功绑定并返回了三个属性校验失败的结果。

分组校验

我们写业务时通常会存在一种情况:新增操作时通常不需要校验参数 Id ,而在修改或删除操作时我们又需要校验参数 Id ,那么对于同一个参数接收类 UserReq ,我们要怎么处理呢?

很简单,首先我们新建一个更新分组,只需要一个普普通通的接口类就行:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

接着我们在UserReq类里新增一个id属性,同时加上 @NotNull 分组校验:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

groups支持传入一个数组,可以传入多个分组,对于 id 属性来说,在更新和删除操作时我们都需要校验该属性。

最后,在Controller里更新接口方法中添加校验分组:

程序员写接口参数校验,总是太多if else?一招让你避免体力活

我们只需要在注解中加上需要校验的 Update 分组就行啦。

【责任编辑:庞桂玉 TEL:(010)68476606】

原文 

http://developer.51cto.com/art/202003/612238.htm

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 程序员写接口参数校验,总是太多if else?一招让你避免体力活

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址