Hello everyone, I am the 32nd student of the Beijing Branch of the IT Cultivation Institute, an honest and kind java programmer.
Today, I would like to share with you the knowledge points that may be used in the fifth task of the official website of the Cultivation Institute:
Parameter verification under SpringMVC
1. Background introduction
1. Based on the idea of separating the front and back ends, the parameter verification of the back end is essential:
(1) Prevent someone from bypassing the front-end and directly injecting data into the back-end interface
(2) Effectively find front-end errors and feedback during testing
2. Several inspection methods:
(1) Use if to judge the parameters obtained directly in the controller layer
Advantages: It's easier to do this than other methods when there are fewer interfaces
Disadvantages: A large amount of code is embedded in the controller, which violates the principle of code reusability
Improvement method: encapsulate if judgment, call different encapsulation classes in the controller for different parameters
(2) Implement the Validator interface provided by spring
Advantages: no configuration files, no annotations, low code coupling
Disadvantages: The reduction of coupling naturally increases the amount of code in the implemented interface class, and aop is very difficult to do
(3) Use the annotation method based on JSR303 and use spring to generate the validator instance
Advantages: You don't need to implement the interface yourself, the use of aop makes a lot of verification convenient
Disadvantages: At least when I use @valid annotation, grouping, ordering, and cascading validation are not supported
Improvement method: spring provides us with a @validated interface, which can be used to complete the above special validation
The above three methods are just the tip of the iceberg of my exposure to parameter validation. There are many validation methods that I haven’t learned yet, but the principles are all based on javax validation, and hibernate validate uses javax validation without exposing its own interface, reducing the amount of code. Intrusive, today I will talk about the latter two methods in combination with the code I wrote.
2. Knowledge analysis
1. About JSR303, 349 and 380
(1) Annotation type
It can be annotated on the fields and properties of javabeans, or on maps and lists. The annotations are very flexible, and can even be directly annotated on the controller interface. In most cases, regular expressions can meet our needs.
(2) Extraction of error information
If it is native writing information, it can be extracted from constraintViolations, which is a set collection, which can be obtained by calling the getMessage method through the iterator.
2. About the validator interface
(1) Two methods that need to be implemented
When we implement the interface, we need to implement its two methods, respectively declaring the class to be verified and the verification standard.
(2) Registration in the controller
Use WebDataBinder to bind our interface implementation class, and the parameters to be verified should be followed by bindingresult.
(3) Extraction of error information
bindingResult.getAllErrors can get the required error information and then process it, or use the error tag of form:form to display the error
3. About spring integration
(1) Internationalization configuration and error message files
You need to inject a factory to generate a validator instance, and extract the error information in the configuration file through EL expressions.
(2) Interfaces that need to be implemented for grouping and order checking
Just declare an interface, you don't need to write anything else
Three, coding practice
4. Frequently Asked Questions
(1) Determine whether the basic type entered by the user is legal
eg: We have to accept the interface of int type and pass a non-int type data
Solution: global exception capture
The problem is: when I wrote it myself, I wanted to write regular but did not support basic types, so I could only give string this type
(2) How to deal with json data
eg: The front end sends a complex json data but the data corresponds to the form
Solution: At this time, the aop aspect processing should not be performed on the controller. It may be a suitable choice to choose an interceptor
The problem is: I wrote the code of the interceptor, but there is no suitable json object for testing. The core idea is to traverse the data and put it into the map for testing.
(3) What if the sent data cannot be directly converted into a model?
eg: The username and verification code sent when logging in correspond to the user model, but there is no field corresponding to the verification code
Solution: do not do aop processing on this interface, I am currently adding another if judgment, which is quite redundant
The problem is: it keeps reporting errors after processing. At the beginning, I didn't realize that the test must actually correspond to the model model, that is, the data in our database.
(4) Do so many parameters to check whether it will affect the processing speed of our interface
I haven't tried the if statement, but aop has little effect on the speed
5. References
https://blog.csdn.net/csyuyaoxiadn/article/details/56016359
https://blog.csdn.net/u012881904/article/details/77197015
http://beanvalidation.org/2.0/spec/2.0.0.cr2/#_evaluation_license
6. More discussion
thanks
This small class is more based on my own code to explain, there must be many mistakes and limitations
Thanks for watching, please correct me if there is any mistake