参数校验放在controller还是service_极致优雅，零侵入的全局异常处理、参数校验、错误码、统一响应格式解决方案...

最新推荐文章于 2022-04-22 14:53:05 发布
最新推荐文章于 2022-04-22 14:53:05 发布
阅读量1k 收藏 7
点赞数
文章标签： 参数校验放在controller还是service 查询 service monitor 时发生内部错误

baea5037aa64de4cfe09a958b7d6b77b.png

1. 需求背景

在前后端分离的开发场景下，通常的Controller伪代码是这样的:

@GetMapping
@ResponseBody
public Result GeneralPageQuery(Parameter params) {

    Result result = new Result();

    //1. 校验params参数，非空校验、长度校验

    try{

        //2. 调用Service的一系列操作
    }catch(Exception e){

        //3. 异常处理：一堆丑陋的try...catch，如果有错误码的，还需要手工填充错误码
    }

    return result;
}

或者这样：

@RequestMapping(value = "/content", method = RequestMethod.GET)
@ResponseBody
public CommonResult content() {
    HomeContentResult contentResult = homeService.content();
    return CommonResult.success(contentResult);
}

以上代码均来自github高星流行的项目，通常存在以下几种问题：

  • 手工进行封装统一响应格式

    为方便移动端处理接口返回值，通常要求将结果按照约定的格式封装起来。这个封装的操作大部分开发人员都是自己完成的。例如上文中的

    Result result = new Result();
    CommonResult.success(contentResult);

    每一个接口都需要开发人员手工创建一个Result、CommonResult，属于低效的重复劳动。

    一般的，通常需要将处理结果封装到类似如下格式的Java Bean中

    public class ResponseBean{
        private int code ;
        private String msg ;
        private Object data ;
    }

    每次有返回结果时，执行

    ResponseBean bean=new ResponseBean();
    bean.setData(data);
    return bean;

  • 混乱的异常处理体系

    虽然@ExceptionHandler已经存在了很多年，但是很多程序员还是习惯在每个接口进行异常捕获，然后根据不同的异常，封装异常码到上述的Result、CommonResult中，满篇的try……catch既显得代码冗余，也影响开发效率，还影响代码的可读性。

    对外提供的API，处理业务逻辑时发生了异常，不能直接给调用方返回异常堆栈信息，而是要返回这个异常对应的错误码，便于双方开发人员对接。

    异常类并没有和异常错误码进行关联，在抛出异常时，需要到枚举类、到定义类中找到异常对应的异常码，既容易出错，也非常低效。

  • 接口参数校验及错误提示

    接口参数的某些校验属于重复体力劳动，例如非空校验、长度校验等，可以交给类似Hibernate Validator 这样的Bean Validation框架进行处理。

    Validator校验出来的异常，还需要跟匹配成开发者自定义的异常，方便返回错误码。

  • Http异常转换

    在进行REST微服务开发时，Http协议本身会返回各种状态码，我们希望统一转成200，并返回自定义的异常码。

以上所有问题，global-result-handler-starter一次性解决。

2. global-result-handler-starter案例代码

以下是使用global-result-handler-starter进行开发的代码：

@PostMapping
public Long add(@RequestBody TaskDTO.Info info) {
    if(log.isDebugEnabled()){
        log.debug("TaskDTO.Info=[{}]",gson.toJson(info));
    }
    return taskService.add(info);
}

@GetMapping
public TaskDTO.Page pageList(TaskDTO.Query query) {

    if(log.isDebugEnabled()){
        log.debug("TaskDTO.Query=[{}]",gson.toJson(query));
    }
   TaskDTO.Page page= taskService.pageList(query);
   if(log.isDebugEnabled()){
        log.debug("TaskDTO.Page=[{}]",gson.toJson(page));
    }
   return page;
}

@GetMapping("/{id}")
public TaskDTO.DetailInfo detail(@PathVariable Long id) {

    if(log.isDebugEnabled()){
        log.debug("Getting Task detail,id=[{}]",id);
    }
    TaskDTO.DetailInfo detailInfo = taskService.getById(id);
    if(log.isDebugEnabled()){
        log.debug("Task detail=[{}]",gson.toJson(detailInfo));
    }
    return detailInfo;
}

@PutMapping("/{id}")
public void update(@PathVariable String id, TaskDTO.Info info) {
    if(log.isDebugEnabled()){
        log.debug("TaskDTO.Info=[{}]",gson.toJson(info));
    }
    taskService.updateById(info);
}

@DeleteMapping("/{id}")
public void delete(@PathVariable Long id) {
    if(log.isDebugEnabled()){
        log.debug("Deleting Task ,id=[{}]",id);
    }
    taskService.deleteById(id);
}

以上代码具有以下特点

  • 代码优雅、简洁、直观

  • 在DTO中结合Validator进行校验

  • 直接返回所需要的结果，不需要每个接口都new ResponseBean()

  • 统一异常处理，业务异常结合异常码，也是阿里巴巴《Java开发手册》所推荐的

    异常的抛出主要在service层，例如

    public TaskDTO.Info getInfoById(Long id) {
      Task info = taskExMapper.selectByPrimaryKey(id);
      if(info == null){
          throw new CommonException.NotFoundException();
      }
      return entity2Info(info);
    }

    而CommonException.NotFoundException异常在抛出时，已经定义了异常码

    @ExceptionMapper(code = 1404,msg = "Not found！")
    public static class NotFoundException extends RuntimeException {
    }

3. global-result-handler-starter使用教程

3.1 引入starter

global-result-handler-starter目前已发布到Maven中央仓库，可以直接在项目的pom文件中引入。

<dependency>
  <groupId>com.feiniaojin.grhgroupId>
  <artifactId>global-result-handler-starterartifactId>
  <version>0.3version>
dependency>

  • 目前可用的版本是0.3

3.2 在启动类上通过注解开启统一处理

@EnableGlobalResultHandler
@SpringBootApplication
public class ExampleApplication {
  public static void main(String[] args) {
    SpringApplication.run(ExampleApplication.class, args);
  }
}

3.3 在DTO中设置校验

grh的接口参数校验，采用的是Hibernate Validator原生的方法，并未提供任何新增的校验方法，保证了代码的可移植性，只要是Hibernate Validator支持的校验方式，grh即兼容。

如果要扩展Hibernate Validator的校验功能，只要Hibernate Validator支持，则grh也会支持。

@Data
public class RequestDTO {

    @NotNull(message = "userId is null ")
    private Long userId;

    @NotNull(message = "userName is null ")
    @Length(min = 6, max = 12)
    private String userName;

    @NotNull(message = "age is null ")
    @Range(min = 18, max = 50)
    private Integer age;
}

3.4 创建业务异常时加上@ExceptionMapper注解

在创建业务异常时，使用@ExceptionMapper进行注解，并设置异常错误码和提示信息。

推荐实践：同一个模块的业务异常，在同一个"XxxxExceptions"类中创建静态内部类，便于分组和维护，同模块的错误码拥有相同的前缀，例如用户中心相关的异常采用10xx～20xx码段。

public class ExampleExceptions {

    @ExceptionMapper(code = 1024, msg = "UnCheckedException")
    public static class UnCheckedException extends RuntimeException {

    }

    @ExceptionMapper(code = 2048, msg = "CheckedException")
    public static class CheckedException extends Exception {

    }
}

3.5 关闭spring mvc的自动匹配

spring:
  mvc:
    throw-exception-if-no-handler-found: true
  resources:
    add-mappings: false

3.6 实现具体业务逻辑

以下代码来自example工程的ExampleController

/**
 * class {@code ExampleController} 使用案例的Controller.
 *
 * @author feiniaojin
 */
@Controller
@RequestMapping("/example")
@Slf4j
@Validated
@Api("ExampleController")
public class ExampleController {

  @Resource
  private ExampleService exampleService;

  /**
   * 测试空返回值.
   */
  @RequestMapping("/void")
  @ResponseBody
  @ApiOperation(value = "测试返回空值", notes = "")
  public void testVoidResponse() {

  }

  @RequestMapping("/validate")
  @ResponseBody
  public void testValidateException(@Validated RequestDto dto) {
    log.info(dto.toString());
  }

  @RequestMapping("/success")
  @ResponseBody
  public RequestDto testSuccess(@Validated RequestDto dto) {
    log.info(dto.toString());
    return dto;
  }

  @RequestMapping("/get")
  @ResponseBody
  public ResponseDto get(Long id) {
    log.info("id=" + id);
    return exampleService.getById(id);
  }

  /**
   * 测试抛出运行时异常的处理.
   *
   * @param dto 入参
   * @return 直接返回，未处理
   */
  @RequestMapping("/runtime")
  @ResponseBody
  public RequestDto testRuntimeException(RequestDto dto) {
    log.info(dto.toString());
    exampleService.testUnCheckedException();
    return dto;
  }

  /**
   * 测试受检异常的情形.
   *
   * @param dto 入参
   * @return 未处理，直接将入参返回
   * @throws Exception 首检异常
   */
  @RequestMapping("/checked")
  @ResponseBody
  public RequestDto testCheckedException(RequestDto dto) throws Exception {
    log.info(dto.toString());
    exampleService.testCheckedException();
    return dto;
  }

  /**
   * 测试抛出{@code Throwable} 的情形.
   *
   * @param dto 入参
   * @return 未处理，直接返回
   * @throws Throwable 抛出Throwable异常
   */
  @RequestMapping("/throwable")
  @ResponseBody
  public RequestDto testThrowable(RequestDto dto) throws Throwable {
    log.info(dto.toString());
    throw new Throwable();
  }

  /**
   * 测试Controller中方法对参数进行校验的情形.
   *
   * @param userId 非空
   */
  @RequestMapping("/method")
  @ResponseBody
  public void testMethod(@NotNull Long userId) {
    log.info("" + userId);

  }

  /**
   * 不支持的http方法调用.
   * POST接口，使用GET进行请求
   *
   * @param userId
   */
  @RequestMapping(value = "/methodPost", method = RequestMethod.POST)
  @ResponseBody
  public void testMethodNotSupport(Long userId) {
    log.info("" + userId);

  }

  /**
   * 测试Controller中方法对参数进行校验的情形.
   */
  @RequestMapping("/jsonStr")
  @ResponseBody
  public String jsonStr() {
    log.info("");
    return "jsonStr";
  }

  /**
   * 测试Controller中方法对参数进行校验的情形.
   */
  @RequestMapping("/str")
  public String str() {
    log.info("");
    return "view";
  }
}

3.7 demo工程的结构

ae3a57ab9ed09653e4ca155876ee67fd.png

3.8 Swagger2支持

从0.2版本开始，添加对Swagger2的支持。

  • 添加Swagger2的依赖，目前只测试了2.6.0版本的

    <dependency>
      <groupId>io.springfoxgroupId>
      <artifactId>springfox-swagger-uiartifactId>
      <version>2.6.0version>
    dependency>
    <dependency>
      <groupId>io.springfoxgroupId>
      <artifactId>springfox-swagger2artifactId>
      <version>2.6.0version>
    dependency>

  • 在工程中添加springmvc的静态路径

    spring:
    mvc:
      throw-exception-if-no-handler-found: true
      static-path-pattern: "*.html"
      add-mappings: false

    如果不添加，grh将会拦截html

3.9 自定义返回格式和默认异常码

从0.3版本开始，支持自定义默认异常码和统一返回的格式。

要支持自定义默认异常码和统一返回的格式，可以参考global-result-handler-defaults，该模块提供了很多默认的实现。

具体步骤如下：

3.9.1 增加maven依赖

增加global-result-handler-def的依赖

<dependency>
    <groupId>com.feiniaojin.grhgroupId>
    <artifactId>global-result-handler-defartifactId>
    <version>0.3version>
dependency>

global-result-handler-def只有一些定义的interface注解，不包含任何实现，也不包含任何第三方库，可以直接在api接口定义中引入。

3.9.2 提供自定义实现

参考global-result-handler-defaults，对需要自定义的内容进行实现。

3.9.3 Spring Boot中配置实例化

将自定义的组件配置到Spring Boot中，即可替换默认的实现。

4. 版本历史

0.1

基本功能的实现，用于作者个人项目，实现的功能有：

  • 统一异常处理

  • 参数校验并返回

  • 统一返回格式

  • 异常与错误码关联

0.2

  • 增加对swagger的支持

0.3

  • 支持自定义默认错误码

  • 支持自定义返回格式

  • 支持自定义http状态码与异常关联

  • 支持自定义参数校验异常与异常关联

  • example工程中测试spring boot跳转静态页面

5. 源码地址

以上的所有实现，是基于笔者在实际开发中的需求进行抽象设计的，未必适合所有的情形。

该项目的源码已上传至github，有需要的同学可以clone下来进行二次开发，欢迎提交PR。

github:

starter: https://github.com/feiniaojin/global-result-handler.git

example: https://github.com/feiniaojin/global-result-handler-starter-example.git

global-result-handler-starter-example需要搭配对应版本的global-result-handler-starter，二者的版本号一致。

联系方式：

微信：qyj000100

邮箱：943868899@qq.com

weixin_39778214
关注
Spring Boot进阶(45): Spring Boot 开发必备技能：如何优雅地返回统一结果包装！
**My Coding Family**
06-15 1744
Spring Boot 如何返回统一结果包装？一文教会你。
controller方法要trycatch吗_项目里到处是try catch ，终于找到一次搞定 Exception ^ ^小技巧...
weixin_36316642的博客
11-29 1312
来源：巨人大哥cnblogs.com/jurendage/p/11255197.html什么是统一异常处理目标统一异常处理实战总结背景软件开发过程中，...
SpringMVC参数校验
KHOST的博客
06-07 547
# 前言 在 Web 开发中, 我们经常需要校验各种参数，这是一件繁琐又重要的事情，对于很多人来说，在做参数校验的时候，会有以下几种类型的处理方式。 # 甩锅型 校验太麻烦了，让客户端去负责校验就行了，调用方传错了是调用方的问题，不是服务的问题，甩个 500 错误让他们好好反省： # 劳模型 有多少参数，我就写多少个 if 语句做判断，校验不通过的都写一句...
参数校验放在controller还是service_让你的代码更加简练-springboot使用JSR303校验
weixin_39966765的博客
11-29 517
痛点​​相信不少人写过这样都代码，对方法入参进行了各种校验。上面还是比较少的校验。如果遇到什么邮箱、手机号更复杂，对格式也需要进行校验。可能洋洋洒洒几百行代码就过去了。这种代码其实跟业务流程没有太多关系，但是又不能不做。那么有没有一种方法可以避免呢。当然有！就是JSR-303(JSR是指向JCP(Java Community Process)提出新增一个标准化技术规范的正式请求，是Java界的一个...
五分钟带你了解Java是如何从容而优雅地实现接口数据校验
Hanko的专栏
12-09 249
本篇文章给大家分享平时开发中总结的一点小技巧！在工作中写过Java程序的朋友都知道，目前使用Java开发服务最主流的方式就是通过Spring MVC定义一个Controller层接口，并将接口请求或返回参数分别定义在一个Java实体类中，这样Spring MVC在接收到Http请求(POST/GET)后，就会自动将请求报文自动映射成一个Java对象。这样的代码通常是这样写的： @RestController public class OrderController { @Autowired
参数校验放在controller还是service_@Validated校验的实践
weixin_39892800的博客
11-27 2283
spring-boot中可以用@validated来校验数据，如果数据异常则会统一抛出异常，方便异常中心统一处理。一、简单使用1、Controller上开启验证2、DTO上申明被验证的字段a、声明需要被校验的字段3、附上部分标签含义二、@Validated分组1、Controller上开启验证2、DTO上申明被验证的字段a、创建分组接口类b、声明需要被校验的字段三、集合校验如果我们直接使...
优秀的 Java 项目，代码都是如何分层的？
程序员小乐
09-27 1548
点击上方 "程序员小乐"关注,星标或置顶一起成长每天凌晨00点00分,第一时间与你相约每日英文Things in this world are tempora...
优秀的代码都是如何分层的？
程序员闪充宝
10-18 281
点击上方蓝色字体，选择“标星公众号”优质文章，第一时间送达作者：咖啡拿铁juejin.im/post/5b44e62e6fb9a04fc030f2161、背景说起应用分层，大部分人都会认...
SpringMVC之参数检验篇
pongandnoon的博客
09-17 1944
项目开发中我们经常需要对接口参数进行检验，有些参数必须有值，有些参数比如手机号，身份证号必须符合一定的格式规范。如果把参数检验都写在业务代码中，会造成业务代码又长又杂，且每个接口都得去校验，影响开发效率以及代码质量。有没有方法可以把参数检验统一在一个地方进行，不对我们的业务代码进行干扰呢？ SpringMVC给我们提供了一些支持数据校验的注解，如@NotNull,@NotBlank,@Lengt...
SpringMVC源码分析之异常处理机制
热门推荐
liushangzaibeijing的博客
11-28 6万+
本篇博文从ExceptionResolver接口出发，介绍了其springMVC整个异常处理的UML类图结构，并对其相关子类进行详尽的分析、应用进行讲解，所有的子类源码分析都使用了例子和源码分析结合的方法进行阐述异常，读者可以通过这篇文章较好的了解springMVC异常处理机制以及应用场景。希望可以帮到大家
为什么不建议用try catch处理异常？
weixin_59371031的博客
04-22 347
软件开发过程中，不可避免的是需要处理各种异常，就我自己来说，至少有一半以上的时间都是在处理各种异常情况，所以代码中就会出现大量的 try {...} catch {...} finally {...}代码块，不仅有大量的冗余代码，而且还影响代码的可读性。 比较下面两张图，看看您现在编写的代码属于哪一种风格？然后哪种编码风格您更喜欢？ 丑陋的 try catch 代码块： 优雅的 Controller： 上面的示例，还只是在 Controller 层，如果是在 Service 层，可能会有更.
java中参数校验
xisuo002的博客
07-18 1118
1.常见的验证的方式 前端的校验是必须的，这个很简单，因为客户体验。后台的校验更是必须的，关键在于如何与目前我们的分层思想（控制层、业务层、持久层）综合起来考虑。在每层都要进行校验吗？还是只在是某个特定层做就可以了？是否有好的校验框架（如前端的jquery校验框架、springmvc校验框架）？总之校验框架还是有很多的，原理不就是对后端接收的数据进行特定规则的判断，那我们怎么制定规则，有怎么去检...
springboot 数据验证是放在Controller层还是Service层
qq_42339350的博客
10-28 5670
规范性验证放在Controller层 例如不能为空，不能为null等基本的规范性验证。前端也验证过了，后端验证确保健壮。但其实它不属于任何业务。而且Spring boot 里面的 @Validated,@NotNull @NotBlank 校验注解也是放在Controller层的。所以规范性校验放在Controller层是大家都比较认可的。 业务性验证放在Service层 需要查询数据库的，比如用户名不能重复，这种校验放在service层比较合适。因为与业务挂钩了。我有可能业务需求是用户名第一个字不能重复，
java unexpected type_Java如何用最低的成本，提高你的Java代码稳壮性。
weixin_29532173的博客
02-24 345
age应该用Integer类型，昨晚没注意看异常，但是文中整体思路和实现方式是没问题的。配置参数启动时校验如果配置文件没有相关的配置，那么启动时就会出现以下异常:Description:Binding to target com.toby.provide.ApplicationProperties@31da6b2e xiaogege:Property: feichao.info.nameValue...
在 Spring/Spring Boot 中实现优雅地参数校验
weixin_47933000的博客
05-12 349
最近在写项目的时候,在每一个controller都充满了大量的if来校验参数,而且每一个controller还不同,不能把校验的方法封装起来.特别麻烦. 最普通的做法就像下面这样。我们通过 if/else 语句对请求的每一个参数一一校验。 if ( StringUtils.isBlank(dto.getFwsz().get(i).getFwmc()) || dto.getFwsz().ge
Spring Boot中的参数校验
xiaoyi52的专栏
07-18 2338
在软件开发中，通常需要对参数进行校验，比如某些参数不能为空，而且不光前端要校验，后端也要校验。那么后端在哪里校验参数？是在控制层还是service层？参数校验有多种实现方式，采用哪一种校验方式呢？ 一般来说，把无业务语义的校验放在action层，用validation做校验，比如数据类型，是否为空，数据长度、格式等，有业务语义的校验放在service层。当然实际中往往并没有那么清晰，当校验足够简单时
Java中controller层和service代码应该怎么分配？
haochajin的博客
09-02 7905
相信大家对SpringMVC的架构都比较清楚了。Spring MVC是Spring框架的一部分，Spring框架成为Java EE开发主流框架后，Spring开发小组又在Spring框架的基础上推出了MVC架构，主要用于支持WEB应用程序的开发。MVC是Model（模型，也称为数据模型）、View（视图）、Controll（控制器）三个英文单词首字母的缩写。从MVC组合的三个单词也可以看出，MV...
实现登录验证功能Service实现类中抛的异常
PaintD的博客
03-29 112
package com.atguigu.atcrowdfunding.exception; //为什么继承runtionException而不是Exception？ //因为spring的默认事务回滚是只对runtionException生效； public class loginException extends RuntimeException { public loginException() {} public loginException(String message) { super(messa
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值