In system development, we ensure the correctness, consistency and security of the input data through a series of rule verifications.
Verification is not just about ensuring that the right user has the right permissions, focusing on “who you are” and “what can you do”, but also about “doing it right”, and the accuracy of data quality can also lead to security issues for verification.
Missing checks can cause defects, and excessive checks can make the code cumbersome.
User: Fill in the form data and submit
System: throw new RestException
User: Fill in the mobile phone number
System: throw new RestException
User: Modify the mailbox format
System: throw new BusinessException
User: Change a mailbox
System: throw new DAOException (“username too long, insert failed”)
User:…
For simple required or length checks, the front end needs to do it, but the back end also needs to do a verification.
Should validation be placed at the controller layer or at the service layer?
1, in the controller to do, the service does not do, the reason is that if the two service methods A.method(), B.method() are called, the two services do a duplicate check.
2, in the service to do, the controller does not do, the reason is that the simple check has been stopped by the front end, business-related verification should be done by the specific service, business-related things to the controller is not appropriate.
3, controller, service each do their own, controller does simple parameter verification, service does business-related verification, and the above registration example is consistent.
4. Do it at all levels, such as the final interception at the DAO layer, to ensure that there will be no data problems.
There are specialized validation standards in Java, Bean Validation 1.0 (JSR 303), Bean Validation 1.1 (JSR 349), and Bean Validation 2.0 (JSR 380).
JSR, short for Java Specification Requests, means Java Specification Proposal. is a formal request to the JCP (Java Community Process) to add a new standardized technical specification. JSR has become an important standard in the Java world.
Jakarta Bean Validation, version 2.0 released for 2019.
In 2009, Oracle acquired SUN and handed over the open source portion to the Eclipse Foundation, but there were commercial requirements, such as not allowing the use of Java EE and other names, so the Foundation changed its name to Jakarta EE. Essentially Jakarta Bean Validation = Java Bean Validation.
We can pull out of the layers and do separate validation against the beans.
The general way of validation can be done with some annotations provided by Bean Validation:
Like what:
If there are many system interfaces, the input parameter level that needs to be checked is relatively large, and the @NotBlank (message = “user account cannot be empty”), this annotation needs to be repeated N many times.
By encapsulating it in one layer, it can be made simpler.
Defines a note @UserCodeNotBlank that means that the user system number cannot be empty, and whose validation logic is in ParamValidation.UserCodeNotBlankValidate.class.
Then define a validation rule
Annotate directly on the user’s bean or on the controller method parameter.
We can also support other common business verification operations, such as verifying that the user role must be a manager.
It is also very suitable for other scenarios to apply this method of verification, such as: