The design idea of verifying request parameters based on Java Bean validation

files from the Hibernate validator:

Data validation is a feature that is used by any application, whether it is a display layer or a persistence layer. In general, the same check logic is scattered across layers, which not only wastes time but also causes duplicate code to occur. To avoid duplication, developers often write these check logic directly into the domain model, but this also mixes the domain model code with the checksum code, which should be the metadata that describes the domain model.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/6E/62/wKiom1V6fwCQfN-RAACyvw5fsaI471.jpg "title=" Domain-model.png "alt=" Wkiom1v6fwcqfn-raacyvw5fsai471.jpg "/>

JSR 303-bean Validation (version 1.1)-defines the metadata model and API for entity validation. The default metadata model is described by annotations, but it can also be overloaded or extended using XML. The bean Validation API is not limited to one layer of the application or to which programming model, for example, Bean Validation can be used on any tier, or in a rich client program like swing.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6E/5E/wKioL1V6gLTAlJ-eAADWJPTcUH0246.jpg "title=" Bean-validator.png "width=" 640 "height=" 315 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:640px;height:315px; "alt=" Wkiol1v6gltalj-eaadwjptcuh0246.jpg "/>

From the above description and diagram can see the data test along with the whole system of the various levels, professional said data validation belongs to the aspect-oriented category.

This article focuses on data validation of HTTP request parameters in Web development.

1. Elicit problems

Here is the 12306 train query API:

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/6E/62/wKiom1V6ge2ijEdPAAGR0401SFQ806.jpg "title=" 12306- Query.png "width=" 680 "height=" 340 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:680px;height:340px; "alt=" Wkiom1v6ge2ijedpaagr0401sfq806.jpg "/>

Note: The above request is PHP, for the moment we switch to servlet.

The request has five parameters, when doing the query will usually do the data validation process, which covers the data format, data validity. For example date to verify the data format, TT will verify the validity of the data (usually the type of train is a fixed number of type code, less change).

In web development, such request parameter verification is a lot of, usually after the front-end of the parameter check, the back end is still need to re-rigorous verification. Then for such non-business code can be extracted out, do data validation alone, if the verification passed, then continue the next business processing, do not pass the corresponding processing.

2. How to Resolve

The above mentioned is to do a separate data check, here the data from the HTTP Request Parameter, the checksum is the work we want to do. The checksum is divided into the validation rules for writing parameters and the processing of check logic.

How to write a validation rule, how to do check logic processing? This introduces the Java Bean Validation specification, which defines the metadata model (which can be considered a validation rule) and the API (the interface for validation processing). Java Bean Validation Specification implementation has hibernate-validator,oval and so on, you can use the Bean validation implementation solution to do this part of the work. The rest is the http Request parameter to the bean mapping, which I call the Bean Parameterbean (parameter entity).

The entire solution is thought of as:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6E/5F/wKioL1V6khiCh4teAAEQhWc3-FE048.jpg "title=" Rpv.png "width=" "height=" 203 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:700px;height:203px; "alt=" Wkiol1v6khich4teaaeqhwc3-fe048.jpg "/>

Process Description: First the request parameters are packaged, packaged into parameter beans, and then through the implementation of the validation API to get the check results of the bean checksum, and finally to verify the results of the next step of specific business processing.

In actual development, we must first define the parameter bean corresponding to the request parameter, and write the validation rules for the bean, which can be either XML configuration or annotation method.

3. Concrete implementation

The specific implementation is to familiarize and apply the Bean Validation specification and its corresponding implementation, and extend more validation rules by customizing. Extract the logic of the request parameters in the business and leave it to the Bean validation module for processing separately.

is a simple implementation class structure diagram for extracting request parameter checksums:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/6E/60/wKioL1V6lBCBuFzOAAO4uekxWYY702.jpg "title=" Request-parameter-validator.png "width=" 780 "height=" 386 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:780px;height : 386px; "alt=" wkiol1v6lbcbufzoaao4uekxwyy702.jpg "/>

In the actual development can be more need for further expansion, and the true dependence of the request parameter Check module interface only parametervalidator this interface, thus separating the request parameter verification, so that its independent and business logic.

This concludes with a "design approach to validating request parameters based on Java Bean Validation", and more ideas to explore and practice.

This article is from the "Red Horse Red" blog, please be sure to keep this source http://aiilive.blog.51cto.com/1925756/1661317

The design idea of verifying request parameters based on Java Bean validation