JSR303帮助我们简化校验

什么是JSR303

        JSR，是Java Specification Requests 的缩写，既Java规范提案。

       JSR 303 是Java EE 6的一个子规范，它是数据检验的一个标准（Bean Validation (JSR 303)）。

为什么使用JSR303

        处理一段业务逻辑，除了前端进行表单数据合法性正确性校验之外，后台也应该对数据合法性正确性进行校验。只有数据在满足我们的业务条件之后，才能进行下一步的业务逻辑。但是不同业务方法可能出现同样的数据校验操作，这样就出现了冗余操作。那么有什么现成的规范可以减少我们的封装或者逻辑，JSR 303是我们必选。

        JSR 303 使用 Bean Validation，即在 Bean 上添加相应的注解，去实现数据校验。这样在执行业务方法前，都会根据注解对数据进行校验，从而减少自定义的校验逻辑，减少代码冗余。

JSR303常见约束

        javax.validation.constraints

详解如下：

代码实现

Step1.

在Bean字段上添加需要的校验注解，并指定需要提示的信息，当然如果不指定会默认从配置文件中读取默认配置。

Step2.

在相关的方法上，使用 @Valid 注解（或者 @Validated 指定组名）标记需要被校验的数据，否则会不生效。

Step3.
　　处理异常。使用 BindingResult 可以获取到检测结果，然后进行处理。
　　也可以使用 全局统一异常 处理（@RestControllerAdvice 与 @ExceptionHandler），处理检测结果。

Step4.

BindingResult处理异常信息 

使用案例

        比如品牌实体-品牌名不能为空，使用@NotBlank，当然可以指定message

比如保存的时候，开启校验，则使用 @Valid 或者  @Validated，检测到数据异常后，会抛出异常

postman测试

 可以这个异常并不是我们想要的异常信息，对于异常处理，我们可以有多种方式，例如：使用BindingResult去处理异常信息，还可以封装全局异常统一处理。

BindingResult处理异常信息

 

 BindingResult可以帮我们处理异常信息，但是每次在业务方法中都需要我们自己去处理异常逻辑，太麻烦，而且代码也会产生很多冗余，可以采用封装统一的异常处理方式简化处理的业务逻辑。

@RestControllerAdvice + @ExceptionHandler 实现全局异常处理

 

 可以看到封装的全局异常并没有起到作用，而且空数据也插入成功了。

那么是什么原因了？

        仔细排查，应该是BindingResult result 参数搞鬼了,删除掉试一下

        删除之后，在测试，果然生效

         那么我们应记住这一点。