SpringBoot2 参数管理实践之入参出参与校验的方式

目录
  • 一、参数管理
  • 二、接收参数
  • 三、响应参数
  • 四、参数校验
    • 1、借鉴参考
    • 2、常用校验方式
  • 五、源代码地址

一、参数管理

在编程系统中,为了能写出良好的代码,会根据是各种设计模式、原则、约束等去规范代码,从而提高代码的可读性、复用性、可修改,实际上个人觉得,如果写出的代码很好,即别人修改也无法破坏原作者的思路和封装,这应该是非常高水准。

但是在日常开发中,碍于很多客观因素,很少有时间去不断思考和优化代码,所以只能从实际情况的角度去思考如何构建系统代码,保证以后自己还能读懂自己的代码,在自己的几年编程中,实际会考虑如下几个方面:代码层级管理,命名和注释统一,合理的设计业务数据库,明确参数风格。

这里就来聊一下参数管理,围绕:入参、校验、返参三个方面内容。

如何理解代码规范这个概念:即大多数开发认同,愿意遵守的约束,例如Spring框架和Mvc模式对于工程的管理,《Java开发手册》中对于业务开发的规定,其根本目的都是想避免随着业务发展,代码演变到无法维护的境界。

二、接收参数

接收参数方式有很多种,List,Map,Object等等,但是为了明确参数的语义,通常都需要设计参数对象的结构并且遵守一定的规范,例如明确禁止Map接收参数:

Rest风格接收单个ID参数:

@GetMapping("/param/single/{id}")
public String paramSingle (@PathVariable Integer id){
    return "Resp:"+id ;
}

接收多个指定的参数:

@GetMapping("/param/multi")
public String paramMulti (@RequestParam("key") String key, @RequestParam("var") String var){
    return "Resp:"+key+var ;
}

基于Java包装对象入参:

@PostMapping("/param/wrap")
public ParamIn paramWrap (@RequestBody ParamIn paramIn){
    return paramIn ;
}

-- 参数对象实体
public class ParamIn {
    private Integer id ;
    private String key ;
    private String var ;
    private String name ;
}

以上是在开发中常用的几种接参方式,这里通常会遵守下面几个习惯:

  • 参数语义:明确接收参数的作用;
  • 个数限制:参数超过三个使用包装对象;
  • 避免多个接口使用单个包装对象入参;
  • 避免包装对象主体过于复杂;

参数接收并没有很复杂的约束,整体上也比较容易遵守,通常的问题在于处理较大主体对象时,容易产生一个包装对象被多处复用,进而导致对象字段属性很多,这种情况在复杂业务中尤其容易出现,这种对象并不利于web层接口使用,或者很多时候都会在业务层和接口层混用对象;

在业务层封装复杂的BO对象来降低业务管理的复杂度,这是合理常见的操作,可以在web接口层面根据接口功能各自管理入参主体,在业务实现的过程中,再传入BO对象中。

避免复杂的业务包装对象在各个层乱飘,如果多个接口入参都是同一个复杂的对象,很容易让开发人员迷茫。

三、响应参数

与参数接收相对应的就是参数响应,参数响应通常具有明确的约束规范:响应主体数据,响应码,描述信息。通常来说就是这样三个核心要素。

响应参数主体:

这里泛型的使用通常用来做主体数据的接收。

public class Resp<T> {

    private int code ;
    private String msg ;
    private T data ;

    public static <T> Resp<T> ok (T data) {
        Resp<T> result = new Resp<>(HttpStatus.OK);
        result.setData(data);
        return result ;
    }

    public Resp (HttpStatus httpStatus) {
        this.code = httpStatus.value();
        this.msg = httpStatus.getReasonPhrase();
    }

    public Resp(int code, String msg, T data) {
        this.code = code;
        this.msg = msg;
        this.data = data;
    }
}

Code状态码

即接口状态,建议参照并遵守HttpStatus中状态码的描述,这是开发普遍遵守的规范,如果不满足业务需求,在适当自定义部分编码,可以完全自定义一套响应码,但是没太多必要。

Msg描述

描述接口的响应的Msg可能就是:成功或失败,更多的时候是需要处理业务异常的提示信息,例如单号不存在,账号冻结等等,通常需要从业务异常中捕获提示信息,并响应页面,或者入参校验不通过的描述。

Data数据

接口响应的主体数据,不同的业务响应的对象肯定不同,所以这里基于泛型机制接收即可,再以JSON格式响应页面。

参考案例

接口返参:

@PostMapping("/resp/wrap")
public Resp<KeyValue> respWrap (@RequestBody KeyValue keyValue){
    return Resp.ok(keyValue) ;
}

响应格式:

{
   "code": 200,
   "msg": "OK",
   "data": {
       "key": "hello",
       "value": "world"
   }
}

四、参数校验

参数接收和响应相对都不是复杂的,比较难处理的就是参数校验:入参约束校验,业务合法性校验,响应参数非空非null校验,等各种场景。

在系统运行过程中,任何参数都不是绝对可靠的,所以参数校验随处可见,不同场景下的参数校验,都有其必要性,但其根本目的都是为了给到请求端提示信息,快速打断流程,快速响应。

1、借鉴参考

很多封装思想,设计模式,或者这里说的参数校验,都可以参考现有Java源码或者优秀的框架,这是一个应该具备的基础意识。

Java原生方法之java.lang.Thread线程:

public void interrupt() {
    if (this != Thread.currentThread())
        checkAccess();
    synchronized (blockerLock) {
        Interruptible b = blocker;
        if (b != null) {
            interrupt0();
            b.interrupt(this);
            return;
        }
    }
    interrupt0();
}

在Java源码中,大部分都是采用原生的if判断方式,对参数执行校验

Spring框架之org.springframework.util.ClassUtils工具类部分代码:

public static Class<?> forName(String name, @Nullable ClassLoader classLoader)
			throws ClassNotFoundException, LinkageError {
		Assert.notNull(name, "Name must not be null");
		Class<?> clazz = resolvePrimitiveClassName(name);
		if (clazz == null) {
			clazz = commonClassCache.get(name);
		}
		if (clazz != null) {
			return clazz;
		}
}

在Spring框架中除了基础的if判断之外,还封装一个org.springframework.util.Assert断言工具类。

2、常用校验方式

If判断

@GetMapping("/check/base")
public String baseCheck (@RequestParam("var") String var){
    if (var == null) {
        return var+" is null" ;
    }
    if ("".equals(var)){
        return var+" is empty" ;
    }
    if ("hello".equals(var)){
        return var+" sensitive word " ;
    }
    return var + " through " ;
}

这种判断在代码中很常见,只是一旦遇到校验的主体对象很大,并且在分布式的环境中,需要重复写if判断的话,容易出错是一个方面,对开发人员的耐心考验是另一个方面。

Valid组件

在早几年的时候,比较流行的常用校验组件Hibernate-Validator,后来兴起的Validation-Api,据说是参考前者实现,不过这并不重要,二者都简化了对JavaBean的校验机制。

基于注解的方式,标记Java对象的字段属性,并设定如果校验失败的提示信息。

public class JavaValid {

    @NotNull(message="ID不能为空")
    private Integer id ;

    @Email(message="邮箱格式异常")
    private String email ;

    @NotEmpty(message = "字段不能为空")
    @Size(min = 2,max = 10,message = "字段长度不合理")
    private String data ;
}

校验结果打印:

public class JavaValidTest {

    private static Validator validator ;

    @BeforeClass
    public static void beforeBuild (){
        validator = Validation.buildDefaultValidatorFactory().getValidator();
    }

    @Test
    public void checkValid (){
        JavaValid valid = new JavaValid(null,"email","data") ;
        Set<ConstraintViolation<JavaValid>> validateInfo = validator.validate(valid) ;
        // 打印校验结果
        validateInfo.stream().forEach(validObj -> {
            System.out.println("validateInfo:"+validObj.getMessage());
        });
    }
}

接口使用:

@PostMapping("/java/valid")
public JavaValid javaValid (@RequestBody @Valid JavaValid javaValid,BindingResult errorMsg){
    if (errorMsg.hasErrors()){
        List<ObjectError> objectErrors = errorMsg.getAllErrors() ;
        objectErrors.stream().forEach(objectError -> {
            logger.info("CheckRes:{}",objectError.getDefaultMessage());
        });
    }
    return javaValid ;
}

这种校验机制基于注解方式,可以大幅度简化普通的入参校验,但是对业务参数的合法校验并不适应,例如常见的ID不存在,状态拦截等。

Assert断言

关于Assert断言方式,起初是在单元测试中常见,后来在各种优秀的框架中开始常见,例如Spring、Mybatis等,然后就开始出现在业务代码中:

public class AssertTest {
    private String varObject ;
    @Before
    public void before (){
        varObject = RandomUtil.randomString(6) ;
    }

    @Test
    public void testEquals (){
        Assert.assertEquals(varObject+"不匹配",varObject,RandomUtil.randomString(6));
    }
    @Test
    public void testEmpty (){
        Assert.assertTrue(StrUtil.isNotEmpty(varObject));
        Assert.assertFalse(varObject+" not empty",StrUtil.isNotEmpty(varObject));
    }
    @Test
    public void testArray (){
        /*
            数组元素不相等: arrays first differed at element [1];
            Expected :u08
            Actual   :mwm
         */
        String var = RandomUtil.randomString(5) ;
        String[] arrOne = new String[]{var,RandomUtil.randomString(3)} ;
        String[] arrTwo = new String[]{var,RandomUtil.randomString(3)} ;
        Assert.assertArrayEquals("数组元素不相等",arrOne,arrTwo);
    }
}

Assert断言,可以替换传统的if判断,大量减少参数校验的代码行数,提高程序的可读性,这种风格是目前比较流行的方式。

五、源代码地址

GitHub·地址https://github.com/cicadasmile/middle-ware-parentGitEE·

地址https://gitee.com/cicadasmile/middle-ware-parent

以上就是SpringBoot2 参数管理实践,入参出参与校验的详细内容,更多关于SpringBoot2 参数校验的资料请关注我们其它相关文章!

(0)

相关推荐

  • SpringBoot @Validated注解实现参数分组校验的方法实例

    前言 在前后端分离开发的时候我们需要用到参数校验,前端需要进行参数校验,后端接口同样的也需要,以防传入不合法的数据. 1.首先还是先导包,导入pom文件. <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> 2.解释一下注解的作用 @N

  • springboot+dubbo+validation 进行rpc参数校验的实现方法

    注意:本文dubbo 版本 2.8.4 springboot 版本 2.0.4.RELEASE 项目结构 test-rest (前端消费着,controller 层,springboot+maven项目) test-api (dubbo服务 的 api ,只记录 service 接口和 model ,maven 项目) test-provider(dubbo 服务提供者,实际的数据库操作及业务层, springboot+maven项目 ) 背景: 使用springmvc做restful,使用du

  • SpringBoot中自定义注解实现参数非空校验的示例

    前言 由于刚写项目不久,在写 web 后台接口时,经常会对前端传入的参数进行一些规则校验,如果入参较少还好,一旦需要校验的参数比较多,那么使用 if 校验会带来大量的重复性工作,并且代码看起来会非常冗余,所以我首先想到能否通过一些手段改进这点,让 Controller 层减少参数校验的冗余代码,提升代码的可阅读性. 经过阅读他人的代码,发现使用 annotation 注解是一个比较方便的手段,SpringBoot 自带的 @RequestParam 注解只会校验请求中该参数是否存在,但是该参数是

  • Springboot使用@Valid 和AOP做参数校验及日志输出问题

    项目背景 最近在项目上对接前端的的时候遇到了几个问题 1.经常要问前端要请求参数 2.要根据请求参数写大量if...else,代码散步在 Controller 中,影响代码质量 3.为了解决问题1,到处记日志,导致到处改代码 解决方案 为了解决这类问题,我使用了@Valid 做参数校验,并使用AOP记录前端请求日志 1.Bean实体类增加注解 对要校验的实体类增加注解,如果实体类中有List结构,就在List上加@Valid @Valid注解 注解 备注 @Null 只能为null @NotNu

  • SpringBoot如何优雅的处理校验参数的方法

    前言 做web开发有一点很烦人就是要校验参数,基本上每个接口都要对参数进行校验,比如一些格式校验 非空校验都是必不可少的.如果参数比较少的话还是容易 处理的一但参数比较多了的话代码中就会出现大量的IF ELSE就比如下面这样: 这个例子只是校验了一下空参数.如果需要验证邮箱格式和手机号格式校验的话代码会更多,所以介绍一下validator通过注解的方式进行校验参数. 什么是Validator Bean Validation是Java定义的一套基于注解的数据校验规范,目前已经从JSR 303的1.

  • Springboot集成JSR303参数校验的方法实现

    JSR303 是一套 JavaBean 参数校验的标准 1.pom导入依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> 2.注解类型 (1)空检查 @Null 验证对象是否为null @NotNull 验证对象是否不为null,

  • SpringBoot2 参数管理实践之入参出参与校验的方式

    目录 一.参数管理 二.接收参数 三.响应参数 四.参数校验 1.借鉴参考 2.常用校验方式 五.源代码地址 一.参数管理 在编程系统中,为了能写出良好的代码,会根据是各种设计模式.原则.约束等去规范代码,从而提高代码的可读性.复用性.可修改,实际上个人觉得,如果写出的代码很好,即别人修改也无法破坏原作者的思路和封装,这应该是非常高水准. 但是在日常开发中,碍于很多客观因素,很少有时间去不断思考和优化代码,所以只能从实际情况的角度去思考如何构建系统代码,保证以后自己还能读懂自己的代码,在自己的几

  • 使用注解@Validated和BindingResult对入参进行非空校验方式

    目录 注解@Validated和BindingResult对入参非空校验 @Validated 和 BindingResult 使用遇到的坑 注解@Validated和BindingResult对入参非空校验 在项目当中少不了入参校验,服务器和浏览器互不信任,不能因为前端加入参判断了后台就不处理了,这样是不对的. 比如前台传过来一个对象作为入参参数,这个对象中有些属性允许为空,有些属性不允许为空.那么你还在使用if()else{}进行非空判断吗?不妨尝试下使用注解,可以使用@Validated和

  • Spring中使用LocalDateTime、LocalDate等参数作为入参

    0x0 背景 项目中使用LocalDateTime系列作为dto中时间的类型,但是spring收到参数后总报错,为了全局配置时间类型转换,尝试了如下3中方法. 注:本文基于Springboot2.0测试,如果无法生效可能是spring版本较低导致的.PS:如果你的Controller中的LocalDate类型的参数啥注解(RequestParam.PathVariable等)都没加,也是会出错的,因为默认情况下,解析这种参数使用ModelAttributeMethodProcessor进行处理,

  • Spring boot如何配置请求的入参和出参json数据格式

    这篇文章主要介绍了spring boot如何配置请求的入参和出参json数据格式,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 请求入参数据格式配置,以日期格式为例: 编写日期编辑器类: import first.zxz.tools.DateUtil; import java.beans.PropertyEditorSupport; /** * 日期编辑器 * * @author zhangxz * @date 2019-11-12 20:01

  • 使用@RequestBody配合@Valid校验入参参数

    目录 @RequestBody配合@Valid校验入参参数 自定义一个Controller 自定义实体类 自定义全局异常处理器 附录 @Valid校验@RequestBody的参数 希望通过注解校验post请求的body 在request实体类添加注解进行校验 可以返回注解配置的错误信息 @RequestBody配合@Valid校验入参参数 自定义一个Controller import com.example.demo.pojo.User; import org.springframework.

  • SpringBoot通过AOP与注解实现入参校验详情

    目录 前言: 注解标记 通过AOP对方法进行增强 测试Get请求 测试POST请求 解决方法代码 再次测试POST请求 前言: 问题源头: 在日常的开发中,在Service层经常会用到对某一些必填参数进行是否存在的校验.比如我在写一个项目管理系统: 这种必填参数少一些还好,如果多一些的话光是if语句就要写一堆.像我这种有代码洁癖的人看着这一堆无用代码更是难受. 如何解决: 在Spring里面有一个非常好用的东西可以对方法进行增强,那就是AOP.AOP可以对方法进行增强,比如:我要校验参数是否存在

  • Mybatis调用PostgreSQL存储过程实现数组入参传递

    前言 项目中用到了Mybatis调用PostgreSQL存储过程(自定义函数)相关操作,由于PostgreSQL自带数组类型,所以有一个自定义函数的入参就是一个int数组,形如: 复制代码 代码如下: CREATE OR REPLACE FUNCTION "public"."func_arr_update"(ids _int4)... 如上所示,参数是一个int数组,Mybatis提供了对调用存储过程的支持,那么PostgreSQL独有的数组类型作为存储过程的参数又

  • shift妙用之解决shell编程中的入参问题

    我说过了,shell是我的常规武器,目前虽然还不纯熟,但是我爱shell这门语言,在Linux下面混,总要写脚本.程序员是有基因,对编程语言是有偏好的,你让我写C代码,我会觉得很爽,会有困难,会有痛苦的摸索和学习,但是,我愿意:学习shell/python,我也很乐意,甚至Lisp这种冷门的语言我也充满了好奇,虽然现在Go和Erlang我一点也不懂,但是我按耐不住对这两种语言的兴趣,只要我抽出手来,一定会和他们缠绵一番.有爱就会有恨,我痛苦地意识到到自己是个很情绪化的程序员,哪怕我一遍遍地骂自己

  • 微信小程序实现元素渐入渐出动画效果封装方法

    开端 之前一直使用堪称"万能"的jQuery处理用户交互的动画,近日开发微信小程序,微信小程序高度限制的语法和功能使开源函数可谓对其"无能为力". 那没办法,只好自己写一个可以让元素渐入渐出的,可复用的函数了.做到类似jQuery show()的效果 原创文章,允许转载分享.但请转载请一定标明出处,这是起码的尊重 本文章阅读前需要对微信小程序的动画api有所了解 先看效果 可以看到,动画效果十分流畅,高度复用,封装好后只需要三行代码实现动画 解决 1.寻根问底,发现

  • MyBatis版本升级导致OffsetDateTime入参解析异常问题复盘

    背景 最近有一个数据统计服务需要升级 SpringBoot 的版本,由 1.5.x.RELEASE 直接升级到 2.3.0.RELEASE ,考虑到没有用到 SpringBoot 的内建 SPI ,升级过程算是顺利.但是出于代码洁癖和版本洁癖,看到项目中依赖的 MyBatis 的版本是 3.4.5 ,相比当时的最新版本 3.5.5 大有落后,于是顺便把它升级到 3.5.5 .升级完毕之后,执行所有现存的集成测试,发现有部分 OffsetDateTime 类型入参的查询方法出现异常,于是进行源码层

随机推荐