Data verification is the most basic module in the design of an enterprise project architecture. Predecessors have said that there is no trust in the data delivered to the day after tomorrow on the interface! Why do you say that? Too often we write programs that feel like background validation doesn’t matter, and that gives others a loophole. I can simulate the request sent by the foreground to the background address, so if I send some code involving system security to the background, the consequences can be out of control. Next we will explain how to verify parameters in the SpringBoot project!

Objective in this chapter

Complete parameter background data verification in SpringBoot project.

Build the project

We directly use the IntelliJ IDEA tool to build a SpringBoot project with pre-imported Web dependencies, as shown in Figure 1:




Figure 1

SpringBoot’s Web component is internally integrated with Hibernate-Validator, so we don’t need to import additional packages for validation. Let’s take a look at what SpringBoot provides for validation.

Built-in validation

SpringBoot adopts hibernate-Validator, so we can directly use hibernate-Validator to perform data verification, as shown in Figure 2:




Figure 2

Using the authentication

Next we create an entity called DemoEntity, add several test fields to the entity and validate each field, as shown in Figure 3 below:




Figure 3

I created three fields in DemoEntity and validated them separately.

Field name: the value is not null check and contains 2 to 10 characters. Field AGE: The minimum age is 1. Field mail: non-null verification, mailbox format.

Next we create a controller called IndexController and verify the data in the form of parameters passed through the page, as shown in Figure 4 below:




Figure 4.

Figure 4 shows that I injected a MessageSource interface object into the controller to format error messages. Output error messages from the incoming error field object (FieldError) in conjunction with hibernate- Validator’s built-in error message file. Hibernate – Validator error messages support internationalization. So when we get the error message we need to pass in the Locale object to get the local internationalization type. The Hibernate – Validator error message file can be found in the corresponding source package, as shown in Figure 5 below:




Figure 5

Let’s test our validation to see if it works.

Run the test

We use the form of SpringBootApplication to start the project. After successful startup, access the address: 127.0.0.1:8080/validator. The interface output is shown in figure 6 below:




Figure 6.

As you can see, SpringBoot validations are working. When we access the address, we don’t pass in any parameters. All error messages are output at the same time.




Figure 7.

The validation framework correctly outputs the error message for the corresponding field, so we can try to enter the correct address. As shown in Figure 8 below:




Figure 8.

The data has been output correctly, the interface has been output correctly, SpringBoot provides internal validation for most of our validation, but if you need some custom validation in the system, what do we do?

Custom authentication

The custom validation requires us to provide two file contents, one is the annotation, and the other is the implementation class corresponding to the annotation inheritance ConstraintValidator. Let’s say we have a situation where we add flag to the DemoEntity and verify that the flag field is only 1,2, and 3.

Custom validation annotations

To create an annotation, we need a validation implementation class that validates the annotation, so an error will be reported. The FlagValidator custom validation annotations are shown in Figure 9 below:




Figure 9.

You can see the @Constraint annotation in Figure 9, passing in a validatedBy field. This is the implementation class type for our custom annotation, as shown in Figure 10:




Figure 10.

The custom validation implementation class has two methods, initializing the validation message and performing the validation.

You get configured annotation content in the initialization validation message method, which is your validation business logic.

Test custom validation

Let’s start by modifying the DemoEntity entity class by adding a Flag field and configuring the @FlagValidator custom annotation, as shown in Figure 11 below:




Figure 11.

Next, we will restart the project and add a flag=0 on the previous basis when accessing the address, as shown in Figure 12 below:




Figure 12

Our custom annotation is in effect, we pass in the correct value, visit the address again, and the interface output should look like figure 13:




Figure 13

Verify that the custom annotations are valid.

conclusion

That’s all for this chapter, which explains how to validate incoming values from the foreground and customize annotations in the SpringBoot project.

This chapter has been uploaded to the code cloud:

SpringBoot source code address: gitee.com/hengboy/spr…

SpringCloud source code address: gitee.com/hengboy/spr…

For SpringBoot related articles, visit: Directory: SpringBoot learning directory

For a series of QueryDSL articles, visit the QueryDSL Generic Query Framework learning directory

For articles in the SpringDataJPA series, visit: Directory: SpringDataJPA Learning directory

SpringBoot related articles please visit: directory: SpringBoot learning directory, thank you for reading!

Welcome to join QQ technical exchange group, common progress.




QQ technical exchange group