This is the sixth day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

preface

This section describes the code of the user information module SysUserController in the Ruoyi-Admin module of Ruoyi-Vue. Today, we will introduce the @ “Validated” annotation, which can simplify the tedious data verification code when adding, deleting, modifying, and checking.

javax.validation

Javax. Validation has a set of annotations that help us validate arguments, saving us a bunch of if else’s

Like in the picture above

@notblank (message = "user account cannot be empty ")
@size (min = 0, Max = 30, message = "User account length cannot exceed 30 characters ")
public String getUserName(a)
{
    return userName;
}
Copy the code

If we use code for verification, then we are faced with

if (StringUtils.isBlank(user.getUserName())) {
    return AjaxResult.error("User account cannot be empty.");
} else if (user.getUserName().length() > 30) {
    return AjaxResult.error("User account length cannot exceed 30 characters.");
}
Copy the code

Javax.validation is a validation attribute, and we need to use javax.validation to validate it when we need it. Hibernate – Validator is one of his implementations. Spring-boot-starter-validation is recommended to prevent validation failure due to versioning problems.

At this point we see that the corresponding annotation validation is in effect.

Adding a dependency without considering the version number will not work. Validation validation will not work if the version number is the same as the version number in spring-boot-starter-validation.

<! -- https://mvnrepository.com/artifact/org.hibernate.validator/hibernate-validator -->
<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>7.0.1. The Final</version>
</dependency>
Copy the code

Method of use

Let’s create a new entity class and verify it to illustrate the methods used by Hibernate-Validator.

@Data
public class SysUser {
    @notblank (message = "id cannot be blank ", groups = {update.class})
    private Integer id;

    @NotBlank(message = "{SysUser.userName.NotBlank}", groups = {Add.class, Update.class})
    @length (min = 6, Max = 20, message = "groups = {add.class, update.class}")
    private String userName;

    @notblank (message = "password cannot be blank ")
    private String password;

    public interface Add {}public interface Update {}}Copy the code

annotations

    @notblank (message = "password cannot be blank ")
    private String password;
Copy the code

Javax.mail. Validation. There are 22 annotations in the constraints, just simple look

Grouping validation

Sometimes we need to use the same entity class for two purposes, such as add once and update once. How do we verify these two application scenarios? This requires a corresponding group on the annotation to indicate which group it belongs to. For example, the above ID attribute should not be empty when updated, but it does not need to be displayed when added. Therefore, we can add group to the entity class to distinguish it, and at the same time, we should add classification to the corresponding Controller

@PostMapping("/testAddValidation")
public boolean testAddValidation(@Validated(SysUser.Add.class) @RequestBody SysUser user) {
    return true;
}
@PostMapping("/testUpdateValidation")
public boolean testUpdateValidation(@Validated(SysUser.Update.class) @RequestBody SysUser user) {
    return true;
}
Copy the code

In this way, adding the corresponding grouping after “Validated” can ensure that the corresponding verification is carried out in accordance with the grouping

It is important to note that if grouping is added, then all attributes in the entire entity class will be added to the grouping, otherwise no validation will be performed

internationalization