Data verification method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a data verification method and device, a nonvolatile storage medium and electronic equipment. The method comprises the following steps: acquiring a dynamic verification rule; packaging the dynamic verification rule into a rule information data structure; establishing a mapping relationship between the dynamic verification rules in the dynamic verification rule set and verifiers in the verifier set; rewriting a verification method of the user-defined constraint verifier, and in an execution process of the verification method, determining a target dynamic verification rule set corresponding to a target attribute field of the to-be-verified target business object; and determining a target verifier matched with a target dynamic verification rule in the target dynamic verification rule set, and verifying the target attribute field through the target verifier. According to the method and the device, the technical problem that the verification rule needs to be frequently changed and codes need to be redeployed due to tight coupling of the verification rule and the business entity object is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of object programming, and in particular, to a data verification method and device, a nonvolatile storage medium and an electronic device. BACKGROUND

[0002] In the development of WEB application software, especially in the JAVA-based server programming environment, in order to ensure the accuracy and compliance of HTTP request parameters, developers usually rely on Spring Validation and HibernateValidator, two mature and powerful parameter verification frameworks. However, in actual use, there is a frequent adjustment requirement of verification rules. The traditional method is to hard-code specific verification rules in the form of annotations into the property definition of the business entity object. This means that whenever the business logic is updated and the parameter verification rules need to be adjusted accordingly, the source code needs to be directly intervened, and the annotations need to be added, deleted or replaced. Subsequently, a series of complex processes such as code recompilation, testing and even deployment need to be experienced before the modified rules take effect. This series of steps obviously causes unnecessary extension of the development cycle.

[0003] At present, there is no effective solution to the above problems. SUMMARY

[0004] The present application provides a data verification method and device, a nonvolatile storage medium and an electronic device to at least solve the technical problem that the verification rules need to be frequently changed and the code needs to be re-deployed due to the tight coupling of the verification rules and the business entity object.

[0005] According to one aspect of the present application, a data verification method is provided, comprising: obtaining dynamic verification rules from a configuration center of a micro-service architecture, wherein the dynamic verification rules at least include: property fields of a business object; encapsulating the verification rules into a rule information data structure, and determining a dynamic verification rule set corresponding to the property fields of the business object through the rule information data structure; obtaining a verifier set from a verifier framework, and establishing a mapping relationship between the dynamic verification rules in the dynamic verification rule set and the verifiers in the verifier set; creating a custom constraint verifier, rewriting a verification method of the custom constraint verifier, and in the execution process of the verification method, determining a target dynamic verification rule set corresponding to a target property field of a target business object to be verified through the rule information data structure; determining a target verifier matching the target dynamic verification rule in the target dynamic verification rule set based on the mapping relationship, and verifying the target property field through the target verifier.

[0006] Optionally, establishing a mapping relationship between dynamic validation rules in the dynamic validation rule set and validators in the validator set includes: extracting validation rule names from the dynamic validation rules; determining the data types corresponding to the attribute fields of the business object; combining the validation rule name and data type into a composite key, and searching for validators matching the composite key in the validator set; and establishing a mapping relationship between dynamic validation rules in the dynamic validation rule set and validators in the validator set based on the search results.

[0007] Optionally, the target dynamic verification rule set corresponding to the target attribute field of the target business object to be verified is determined through the rule information data structure, including: obtaining the fully qualified name of the class to which the target business object belongs and the name of the target attribute field; using the fully qualified name of the class and the name of the target attribute field as the joint query key, querying in the rule information data structure, and outputting the queried target dynamic verification rule set.

[0008] Optionally, the target attribute field is validated by the target validator, including: obtaining the actual value of the target attribute field from the target business object; and calling the validation method of the target validator to validate the actual value.

[0009] Optionally, after validating the target attribute field through the target validator, the method further includes: determining whether the validation result of the target validator is a failure; if the validation result is a failure, obtaining a custom error message pre-bound to the target dynamic validation rule; and setting the custom error message as the final prompt message for validation, wherein the final prompt message is used to replace the default technical error message of the validator framework.

[0010] Optionally, the method further includes: obtaining the invalid method parameter exception class generated due to validation failure in the global exception handling component; extracting the final prompt information from the invalid method parameter exception class; and generating a standardized error response body based on the final prompt information.

[0011] Optionally, creating a custom constraint validator includes: creating a validator implementation class; binding the validator implementation class to a custom validation annotation; and implementing the validation logic declared by the custom validation annotation in the validator implementation class to obtain the custom constraint validator.

[0012] According to still another aspect of the present application, a data verification apparatus is also provided, comprising: a first obtaining module configured to obtain a dynamic verification rule from a configuration center of a micro-service architecture, wherein the dynamic verification rule comprises at least a property field of a business object; encapsulate the dynamic verification rule into a rule information data structure, and determine a dynamic verification rule set corresponding to the property field of the business object through the rule information data structure; a second obtaining module configured to obtain a verifier set from a verifier framework, and establish a mapping relationship between a dynamic verification rule in the dynamic verification rule set and a verifier in the verifier set; a determining module configured to create a custom constraint verifier, rewrite a verification method of the custom constraint verifier, and determine a target dynamic verification rule set corresponding to a target property field of a target business object to be verified through the rule information data structure during execution of the verification method; and a verification module configured to determine a target verifier matching a target dynamic verification rule in the target dynamic verification rule set based on the mapping relationship, and verify the target property field through the target verifier.

[0013] According to still another aspect of the present application, a non-volatile storage medium is also provided, comprising a stored program, wherein the program controls a device where the storage medium is located to execute the above data verification method when the program is running.

[0014] According to still another aspect of the present application, an electronic device is also provided, comprising a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program controls the electronic device to execute the above data verification method when the program is running.

[0015] According to still another aspect of the present application, a computer program is also provided, wherein the computer program is executed by a processor to implement the above data verification method.

[0016] According to still another aspect of the present application, a computer program product is also provided, comprising a non-volatile computer readable storage medium, wherein the non-volatile computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the above data verification method.

[0017] In the present application, dynamic check rules from a configuration center of a micro-service architecture are obtained, wherein the dynamic check rules at least include: attribute fields of a business object; the check rules are encapsulated into a rule information data structure, and through the rule information data structure, a dynamic check rule set corresponding to the attribute fields of the business object is determined; a verifier set from a verifier framework is obtained, and a mapping relationship between the dynamic check rules in the dynamic check rule set and the verifiers in the verifier set is established; a custom constraint verifier is created, a verification method of the custom constraint verifier is rewritten, and in the execution process of the verification method, a target dynamic check rule set corresponding to a target attribute field of a target business object to be verified is determined through the rule information data structure; based on the mapping relationship, a target verifier matching the target dynamic check rule in the target dynamic check rule set is determined, and the target attribute field is checked through the target verifier, so that the purpose of complete decoupling of check rules and business logic is achieved, thereby realizing the technical effect of efficient, flexible and no need to redeploy to adjust the check rules, and further solving the technical problem that due to the tight coupling of check rules and business entity objects, the code needs to be frequently changed and redeployed when modifying the check rules. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings, which are included to provide a further understanding of the present application and are incorporated in and constitute a part of this application, illustrate embodiments of the present application and serve to explain the present application. In the drawings:

[0019] Figure 1 is a flowchart of a data check method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of another data check method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of a data check architecture according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of a first time modification of check rules by Nacos according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of a Swagger interface call return according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of a second time modification of check rules by Nacos according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of another Swagger interface call return according to an embodiment of the present application;

[0026] Figure 8 is a structural diagram of a data verification device according to an embodiment of the application;

[0027] Figure 9 is a hardware structure block diagram of a computer terminal of a data verification method according to an embodiment of the application. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first", "second", and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] According to an embodiment of the present application, a method embodiment of a data verification method is provided. It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.

[0031] Figure 1 is a flowchart of a data verification method according to an embodiment of the present application, as Figure 1 shown, the method comprises the following steps:

[0032] Step S102, obtaining dynamic verification rules from the configuration center of the micro-service architecture, wherein the dynamic verification rules at least include: attribute fields of business objects; encapsulating the dynamic verification rules as a rule information data structure, and determining the dynamic verification rule set corresponding to the attribute fields of the business objects through the rule information data structure.

[0033] Among them, the configuration center, such as Nacos, is used to store and manage dynamic check rules, which is the core component of shared configuration between microservices, and can ensure the real-time update and consistency of configuration rules. Dynamic check rules are different from traditional static check annotations. They are not hard-coded in the object property definition of the business entity class, but are stored in the configuration center in the form of key-value pairs. The key here can be the combination of the name of the business entity and its specific attribute field, and the value describes the check standard that the field should follow in detail, such as maximum length, minimum value, whether to allow null, etc.

[0034] The attribute field of the business object refers to the specific variable in the various data models defined when developing the WEB application, such as the username, password, email, age, etc. in a User class. These fields in traditional check rules will directly use annotations such as @NotNull, @Size, @Email, @Min, etc. to define the check logic.

[0035] The rule information data structure is a data organization form used to organize and store dynamic check rules, and its design purpose is to efficiently manage and query these rules, so that the applicable check rule set can be quickly found according to the attributes of different business objects. Specifically, the rule information data structure can be a multi-level mapping (Map), where each level of mapping represents information of different dimensions. For example, the outermost mapping can use the fully qualified class name of the business object as the key, the inner mapping uses the specific attribute field name as the key, and the deepest layer value is a list or set containing all the check rules of the field.

[0036] Specifically, the dynamic check rule set corresponding to the attribute field of the business object can be determined in the following way: First, the key of the field in the data structure needs to be identified. This key is a string composed of the fully qualified class name of the business object and the attribute field name. Then, use this key to get the value from the HashMap, which is the rule set. That is, an indexing and positioning operation of dynamic check rules, which ensures that all related check rules can be accurately called when checking, and then the check logic is processed through the custom verifier. For example, for the age field of the User class, first construct the key "User.age", then retrieve from the ruleInfoDataStructure to get the rule set containing max and min limits.

[0037] Step S102 realizes the separation of the verification logic and the business object attribute field by obtaining the dynamic verification rule from the configuration center of the micro-service architecture, that is, the rule is no longer hard-coded in the annotation of the business object. The complexity of the business code is reduced, and the readability and maintainability of the code are improved. The configuration center supports dynamic updating, and the verification rule can take effect in real time without restarting the service, which significantly shortens the effective time after the rule changes and improves the operation and maintenance efficiency and business response speed. The dynamic verification rule is encapsulated as a data structure to ensure quick and accurate positioning of the verification rule of the specific attribute of the business object, accelerating the verification process and simplifying the search and use of the rule in the verifier logic.

[0038] Step S104 obtains the verifier set from the verifier framework and establishes a mapping relationship between the dynamic verification rules in the dynamic verification rule set and the verifiers in the verifier set.

[0039] The verifier framework is, for example, Hibernate Validator. Hibernate Validator provides a variety of predefined verifiers, such as MaxValidator, MinValidator, SizeValidator, NotNullValidator, etc., which correspond to different types of verification rules, such as the maximum value of the numerical value, the minimum value, the size of the collection or string, whether to allow null, etc. Each rule in the dynamic verification rule set obtained from the configuration center is associated with one or more specific verifiers in the verifier set. For example, for the rule "max = 100", MaxValidator is identified and mapped, and for the rule "size = 5", SizeValidator should be mapped.

[0040] Step S104 establishes the mapping between the dynamic verification rule and the verifier in the framework, and based on different rules, different verifiers are called to perform verification without modifying the verifier code, which improves the dynamic configuration and execution ability of the verification strategy.

[0041] Step S106 creates a custom constraint verifier, rewrites the verification method of the custom constraint verifier, and in the execution process of the verification method, determines the target dynamic verification rule set corresponding to the target attribute field of the target business object to be verified through the rule information data structure.

[0042] In step S106, first, creating a custom constraint validator needs to define a custom annotation, such as in the use of @DynamicValid, and make it as a target business object property field verification mark. The role of this custom annotation is similar to the standard annotations such as @NotNull, @Size, but it has no predefined validation logic, and its real validation behavior will be implemented in the custom constraint validator.

[0043] Next, the verification method isValid() of the custom constraint validator is rewritten, and the isValid() method is the entry point called by the Hibernate Validator framework when performing validation. In the process of rewriting isValid(), the reference to the rule information data structure is introduced to dynamically find the matching verification rule set of the target property field when the method is executed.

[0044] Specifically, when the isValid() method is called, the target business object instance to be verified and its target property field are received as parameters. At this time, the custom constraint validator will use the previously established rule information data structure (encapsulated in step S102) to find the corresponding target dynamic verification rule set through the business object class name and the property field name as the key. The above-mentioned finding process is dynamic, which means that even during the application running time, the update of the verification rule can be reflected and applied immediately without stopping and redeploying. For example, when processing the User.age field, the custom constraint validator will extract all dynamic verification rules related to the age field from the rule information data structure, such as max and min value limits. The custom constraint validator will call the validators associated with these rules (mapping relationship established in step S104) according to the obtained dynamic verification rule set to perform actual verification on the target property field. For example, for the max value limit, MaxValidator will be called; for the min value limit, MinValidator will be called. The validator will check the field value according to the defined verification logic, and return the verification result.

[0045] The verification method of the custom constraint validator after step S106 is rewritten, which can automatically select and configure the validator according to the specific dynamic rule at the current time to perform verification, which makes the verification process adapt to the real-time change of the rule.

[0046] Step S108, based on the mapping relationship, determines the target validator matching the target dynamic verification rule in the target dynamic verification rule set, and verifies the target property field through the target validator.

[0047] In step S108, based on the mapping relationship established in step S104, the custom constraint validator, upon receiving the target dynamic validation rule set, identifies the validator corresponding to each rule in the set. For example, if the rule set contains two rules, "min=18" and "max=100", then it searches for the matching MinValidator and MaxValidator validators. The target validator is then used to validate the attributes of the target business object to ensure that it conforms to all dynamically set rules.

[0048] By calling validators through mapping relationships, it is easy to handle newly added verification rule types in the future. Simply add new rules and their descriptions in the configuration center, and the corresponding validators will be automatically called through mapping without modifying existing code, thus improving scalability and adaptability to future changes.

[0049] Based on the above steps, the system obtains dynamic validation rules from the configuration center of the microservice architecture. These dynamic validation rules include at least the attribute fields of the business object. The validation rules are encapsulated into a rule information data structure, and the set of dynamic validation rules corresponding to the attribute fields of the business object is determined using this data structure. A set of validators from the validator framework is obtained, and a mapping relationship is established between the dynamic validation rules in the dynamic validation rule set and the validators in the validator set. A custom constraint validator is created, and its validation method is overridden. During the execution of the validation method, the set of target dynamic validation rules corresponding to the target attribute fields of the target business object to be validated is determined using the rule information data structure. Based on the mapping relationship, a target validator matching the target dynamic validation rules in the target dynamic validation rule set is determined, and the target attribute fields are validated using the target validator. This approach achieves complete decoupling between validation rules and business logic, resulting in a highly efficient, flexible, and redeployable technical effect.

[0050] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0051] According to some optional embodiments of this application, the mapping relationship between dynamic validation rules in the dynamic validation rule set and validators in the validator set can be established by the following method: extracting the validation rule name from the dynamic validation rules; determining the data type corresponding to the attribute field of the business object; combining the validation rule name and data type into a composite key, and searching for a validator matching the composite key in the validator set; and establishing the mapping relationship between the dynamic validation rules in the dynamic validation rule set and validators in the validator set based on the search results.

[0052] Specifically, the dynamic validation rules obtained from the configuration center are parsed. The dynamic validation rules can be stored in the form of key-value pairs, where the key can contain the class name of the business object, the attribute field name, and the description of the validation rule. For example, the rule is User:age:max=100,min=18. The specific validation rule names such as max and min need to be extracted from it, because each validation rule in Hibernate Validator corresponds to a specific validator class, such as MaxValidator and MinValidator.

[0053] During the mapping process, different data types (such as Integer, String, List, etc.) will correspond to different types of validators. For example, the max rule of the number type will call MaxValidatorForNumber, and the length rule of the string type will call LengthValidatorForString. Therefore, before establishing the mapping, the attribute field type of the business object needs to be obtained.

[0054] In order to quickly locate the correct validator, the validation rule name and the attribute field data type are combined to form a unique joint key. For example, for the max rule of the User.age field, its joint key can be "max_Number". This joint key will be used as the index of the established mapping relationship table to help find the matching validator in the validator set. With the joint key, the validator matching the joint key can be searched in the preloaded validator set.

[0055] Determining the validator matching the dynamic validation rule can establish the mapping relationship between the two. A hash table (Map) can be used to store it, where the joint key is used as the key and the validator instance is used as the value. For example, {"max_Number":MaxValidatorForNumber,"min_Number":MinValidatorForNumber}. In this way, when the validation needs to be performed in the custom constraint validator, the validator associated with the joint key in the dynamic rule can be directly found.

[0056] According to some optional embodiments of the present application, the target dynamic validation rule set corresponding to the target attribute field of the target business object to be verified can be determined through the rule information data structure by the following method: obtaining the class full name to which the target business object belongs and the name of the target attribute field; taking the class full name and the name of the target attribute field as the joint query key, querying in the rule information data structure, and outputting the target dynamic validation rule set obtained by querying.

[0057] Wherein, the class-qualified name refers to the complete namespace path of the class to which the business object belongs, such as com.example.service.User. The class-qualified name is used to uniquely identify the type of the business object, because in a large system, there can be multiple classes with the same or similar attribute field names, and therefore, the class-qualified name is a prerequisite for obtaining the correct validation rule. The name of the target attribute field refers to a specific attribute field that needs to be validated, such as age or userName.

[0058] In order to efficiently query the validation rule of a specific attribute field of a specific business object in the rule information data structure, the combination of the class-qualified name and the attribute field name is used as the query key.

[0059] For example, if the data structure is designed based on HashMap, there can be the following key-value pairs:

[0060] "com.example.service.User_age"→[Rule:max=100,Rule:min=18]

[0061] "com.example.service.Product_name"→[Rule:notBlank=true,Rule:size=max=50,min=2].

[0062] The key "com.example.service.User_age" here is a joint query key, through which the validation rule set of the age attribute in the User class can be quickly located.

[0063] When a specific attribute field of a business object needs to be validated, the joint query key generated above is used to query in the rule information data structure. Specifically, the class-qualified name of the business object and the name of the target attribute field are combined to form a query key. This query key is used to find the corresponding dynamic validation rule set in the rule information data structure (such as HashMap). If the query is successful, the obtained rule set is parsed to prepare for subsequent validation.

[0064] After the query process is completed, the target dynamic validation rule set obtained by the query is output. This set contains all the validation rules applicable to the current attribute field, which can be multiple or one. For example, the age attribute in the User class can have two validation rules of max and min. The output rule set will be used to create validator instances that match these rules, and then the actual validation of the attribute field of the business object is performed.

[0065] In some optional embodiments of the present application, the target attribute field is checked by the target validator, which can be achieved by the following method: obtaining the actual value of the target attribute field from the target business object; calling the check method of the target validator to check the actual value.

[0066] Specifically, in order to check a certain attribute field, the actual value of the attribute is extracted from the target business object. In the Java environment, this can be done by calling the getter method of the corresponding attribute. For example, if the target business object is an instance of the User class and the attribute field to be checked is age, the current actual value of the age field can be obtained by calling the getUserAge() method. The isValid() method of the target validator is called to check the actual value of the attribute. Here, the "target validator" refers to those validators determined according to the mapping relationship between the dynamic check rule set and the validator set. For example, if the dynamic check rule stipulates that the value of the age field cannot be greater than 100, the check method of the MaxValidatorForNumber validator will be called, passing the actual value of the age field and the rule parameter max = 100. The isValid() method will execute the specific check logic inside, such as checking whether the actual value of the age field is less than or equal to 100, and then returning a Boolean value accordingly - if the value meets the rule, return true; otherwise, if the rule is violated, return false.

[0067] Preferably, the actual value can be checked by the following method: obtaining the actual value of the target attribute field to be checked from the target business object through the reflection mechanism or the getter method; selecting the matching target validator based on the type of the target attribute field and the dynamic check rule configured by Nacos; calling the isValid() method of the target validator, taking the actual value of the attribute and the dynamic check rule parameter as input; the target validator executes its check logic to check whether the actual value meets the dynamically configured check rule, and produces a check result; if the check result indicates that the check fails, obtaining the custom error information pre-bound with the dynamic check rule; setting the custom error information as the final prompt information of the check through the ConstraintValidatorContext; if the check fails, capturing and processing the MethodArgumentNotValidException exception in the global exception handling component, extracting the final prompt information and encapsulating it into the standardized error response body.

[0068] As some optional embodiments of the present application, after the target attribute field is checked by the target verifier, the following steps can be further performed: judging whether the checking result of the target verifier is failure; in the case that the checking result is failure, obtaining the custom error information pre-bound with the target dynamic checking rule; setting the custom error information as the final prompt information of the checking, wherein the final prompt information is used to replace the default technical error message of the verifier framework.

[0069] Further, in the global exception handling component, the method parameter invalid exception class generated due to the checking failure is obtained; in the method parameter invalid exception class, the final prompt information is extracted; and according to the final prompt information, the standardized error response body is generated.

[0070] In the present embodiment, the checking result returned by the target verifier is first checked to confirm whether there is any checking failure. If the isValid() method returns false, it indicates that the attribute value does not conform to the configured checking rule, and the checking fails. In this case, the checking on other rules will not be continued, and the error handling stage is entered. At this time, the custom error information pre-bound with the dynamic checking rule is obtained from the Nacos configuration center. These custom error information is specially configured when the checking rule is configured, aiming to provide more humanized and contextualized error description, for example, “age cannot be less than 18 years old”. The use of custom error information replaces the technical error information provided by Hibernate Validator or Spring Validation framework by default, such as “violates constraint”, which can reduce the understanding difficulty of users and increase the readability of error feedback.

[0071] Then, the custom error information is set as the final prompt information of the checking. This operation can be completed in the ConstraintValidatorContext, and by calling the ConstraintValidatorContext.buildConstraintViolation WithTemplate().addPropertyNode().addConstraintViolation() and other methods, the custom error information can be injected into the exception of checking failure. The purpose of this is to enable the subsequent exception handler to capture these more descriptive error information and present it to the user.

[0072] The global exception handling component further handles the `MethodArgumentNotValidException` exception thrown due to validation failure. `MethodArgumentNotValidException` is an exception thrown by Spring Validation that indicates a method parameter failed validation. After catching such an exception, the exception details are analyzed in depth to extract the previously set final error message. This information has been formatted into an easy-to-understand form, containing the specific reason for the validation failure, rather than just a technical error description.

[0073] Finally, based on the final error message, a standardized error response body is generated. The error response body, for example, is a JSON format response, which includes fields such as error code and error message, for example:

[0074] json

[0075] {

[0076] "code":400,

[0077] "message":"Age must be at least 18 years old",

[0078] "success":false

[0079] }

[0080] Using the above methods, both front-end developers and external API callers can quickly understand the cause of the error and take appropriate measures to correct it, avoiding communication barriers and debugging difficulties caused by default technical error messages.

[0081] Preferably, the final prompt information can be extracted in the method parameter invalid exception class by the following method: capturing the MethodArgumentNotValidException thrown by Spring Validation or Hibernate Validator framework, which is an exception type triggered when a method parameter fails to pass the validation; obtaining the BindingResult object encapsulating all the failed fields and their corresponding error information from the MethodArgumentNotValidException object by using the getBindingResult() method; traversing the FieldError set in the BindingResult object, and each FieldError object represents a failed attribute field; for each FieldError, calling its getDefaultMessage() or getField() and getCode() methods to obtain the specific error message or error code of the failed validation, and the associated field name; combining the field name, error code and error message into a custom error response information, and finally forming a set containing detailed descriptions of all the failed fields and custom error messages; constructing a unified standardized response body, such as a JSON format, according to the combined error response information, so as to facilitate the client to parse and display.

[0082] In some optional embodiments of the present application, the creation of the custom constraint validator can be implemented by the following method: creating a validator implementation class; establishing a binding relationship between the validator implementation class and the custom validation annotation; implementing the validation logic declared by the custom validation annotation in the validator implementation class to obtain the custom constraint validator.

[0083] Specifically, first, the validator implementation class is created. The validator implementation class can inherit from the javax.validation.ConstraintValidator interface and override the isValid() method in the interface. ConstraintValidator is an abstract class in Hibernate Validator for customizing validation behavior, which provides a common interface for all custom validators. The created validator implementation class will undertake the task of checking whether the attributes marked by the specific annotation meet the dynamically configured rules.

[0084] Second, the validator implementation class is bound to the custom validation annotation. This can be done by using the @ConstraintValidator meta-annotation on the validator implementation class, and specifying the custom validation annotation to be bound. For example, suppose a custom validation annotation named DynamicValid and the corresponding validator implementation class DynamicValidator are created, then using @ConstraintValidator(DynamicValid.class) on the DynamicValidator class establishes the binding between them. In this way, whenever the @DynamicValid annotation is used in the code, the framework will automatically call the relevant methods of DynamicValidator to perform validation.

[0085] Finally, the validation logic declared in the custom validation annotation is implemented in the validator implementation class. The isValid() method of the validator implementation class will determine whether the property validation is successful. Inside this method, the specific Hibernate Validator checker can be called to verify the property value according to the dynamically configured rules. If the validator determines that the property value is not legal, a custom error message can also be set through ConstraintValidatorContext, which will replace the default error message provided by the framework, providing users with clearer and more intuitive feedback.

[0086] Figure 2 is a flowchart of another data verification method according to an embodiment of the present application, as shown in Figure 2 The method comprises the following steps:

[0087] Obtain the specific validator list of Hibernate Validator.

[0088] In Java applications, Hibernate Validator provides multiple built-in validators to perform various validation rules, such as MaxValidator, MinValidator, SizeValidator, etc. In order to achieve dynamic configuration and execution of validation rules, first, the collection of all available validators of Hibernate Validator needs to be obtained. This part can be implemented through the dependency injection feature of the Spring framework, such as registering a ConstraintValidatorFactory, and creating or obtaining all validator instances through the factory.

[0089] The mapping relationship between the verification rule and the Hibernate Validator verifier is established. After obtaining the specific verifier list, the next step is to establish a mapping relationship between the verification rule obtained from the Nacos dynamic configuration center and the corresponding Hibernate Validator verifier. It is necessary to parse the rules in Nacos and convert them into a structure that can be understood and processed by Java programs, such as HashMap<String, List <rule>>, where the key can be the business class name_field name, and the value is a list containing specific validation rules (such as {max:100}).

[0090] Encapsulated as a map structure. Annotation name_field type: validator. To simplify the selection and configuration of subsequent validators, the mapping relationship can be further encapsulated into a Map structure of <String, ConstraintValidator>, where the key is a composite identifier composed of the validation annotation name and the field type, such as "Max_Number", and the value is the corresponding HibernateValidator validator instance. This allows quick location of the correct validator at runtime.

[0091] Listen to Nacos updates: Set up a listener on the server to continuously monitor changes in the validation rules configured in Nacos, and automatically update the local rule mapping relationship once changes occur.

[0092] Encapsulate the validation rules as a map structure. Business object: attribute field: [rule1, rule2]. The rule data obtained from Nacos is encapsulated into a Map structure, with the key being the class name of the business object and the value being a Map structure of <String, List <rule>>, where the key is the property name and the value is the list of validation rules for the property. This structure makes the query and application of rules intuitive and efficient.

[0093] Custom dynamic validation annotation. To support dynamic validation for Hibernate Validator and Spring Validation framework, a custom validation annotation, such as @DynamicValid, is defined to replace or complement the original HibernateValidator annotation and is marked on the property fields of the business object to tell the framework that these fields should be validated by dynamic validation rules.

[0094] Identify custom annotations on business object fields. Indicate which fields should be validated according to dynamically configured rules for Hibernate Validator and Spring Validation framework.

[0095] Custom validator (e.g. DynamicFieldValidator) is a key component that inherits from javax.validation.ConstraintValidator interface and overrides the isValid() method to implement the logic of dynamic validation. Inside the isValid() method, it queries the dynamically configured rules based on the input field and value, locates the corresponding Hibernate Validator validator from the mapping relationship, and then performs the actual validation.

[0096] Validation process and exception handling. When the custom validator performs validation, it calls the isValid() method of the Hibernate Validator validator that matches the rule, passing in the actual field value and the validation context (ConstraintValidatorContext).

[0097] Dynamic message setting in validation context. If the validation fails, the custom validator uses the API of ConstraintValidatorContext to set a dynamic failure message, which is obtained from Nacos configuration and related to the specific rule.

[0098] Converts to a MethodArgumentNotValidException exception. When one or more fields fail validation, the Hibernate Validator and Spring Validation framework will throw a MethodArgumentNotValidException exception, carrying detailed information about the failed validation.

[0099] Global exception handling captures exceptions. In the application, there is a global exception handling class (such as a class annotated with @ControllerAdvice) to capture and handle all MethodArgumentNotValidException exceptions. In this processing class, the developer can extract error information and field names from the exception, and then encapsulate this information into the expected response format of the application, such as JSON, and return it to the client to inform the client of the details of the parameter validation failure.

[0100] Figure 3 is a schematic diagram of a data validation architecture according to an embodiment of the present application, Figure 2 The method shown can be based on Figure 3 The architecture shown, such as Figure 3 Nacos dynamically configures the validation rules of the business object. Nacos, as a configuration center, allows developers to store validation rules in the form of key-value pairs. "Dynamic" means that the validation logic can be changed without the need to recompile or deploy the code, which is manifested as follows: Configuration details: developers can define specific rules in Nacos, such as "spring:validation:rules:UserReq:userName" configuring NotBlank and Size rules. Real-time synchronization: the backend service listens to configuration updates in real time through the Nacos client, and once the rules change, it is synchronized to the local without manual intervention.

[0101] Validation rules and Hibernate Validator verifier converter module. This module is responsible for converting the text format of the validation rules obtained from Nacos into specific verifier instances that can be executed by Hibernate Validator, and its key functions include: obtaining all available base verifiers from Hibernate Validator, such as MaxValidator, NotNullValidator, etc. According to the field type and validation rule name, a mapping relationship from the rule to the verifier is established to facilitate quick positioning of the applicable verifier when performing validation.

[0102] Custom verifier module. Inherit from the javax.validation.ConstraintValidator interface and override the isValid method to integrate dynamic verification logic: Use custom verification annotations (such as @DynamicValid) on the fields of the business object to mark those properties that should follow dynamic verification rules. In the isValid method, the cached rule information is called by the class name and property name of the business object to get the dynamic verification rule that should be executed currently. According to the obtained rule, the corresponding Hibernate Validator verifier is found through the mapping relationship established in the preceding, and then the isValid method of the Hibernate Validator verifier is called to perform verification. If the verification fails, the custom verifier uses ConstraintValidatorContext to set the error prompt information obtained from Nacos configuration, so as to display it on the client.

[0103] Hibernate Validator and Spring Validation framework. When the request arrives, the Spring Validation framework recognizes the @DynamicValid annotation, triggering the verification process of the custom verifier. MethodArgumentNotValidException is an exception thrown by Spring Validation when verification fails, which contains all the failed verification information and custom error information. GlobalExceptionHandle listens to all MethodArgumentNotValidException exceptions from Spring Validation. Extract all the fields that failed verification and error information from the exception, encapsulate it into a standard interface response data format, and return it to the client.

[0104] Figure 4 FIG. 1 is a schematic diagram of a Nacos first-time modification verification rule according to an embodiment of the present application, Figure 5 FIG. 2 is a schematic diagram of a Swagger interface call return according to an embodiment of the present application, Figure 6 FIG. 3 is a schematic diagram of a Nacos second-time modification verification rule according to an embodiment of the present application, Figure 7 FIG. 4 is another schematic diagram of a Swagger interface call return according to an embodiment of the present application. As shown in FIG. 4, data verification is specifically performed by the following method. Figures 4 to 7

[0105] Nacos first-time modification verification rule. In the Nacos configuration center, the developer first updates the verification rule as follows:

[0106] Configuration details ​

[0107] - Namespace: szbf-yh-dev

[0108] - Data ID: spring-validate

[0109] - Group: DEFAULT_GROUP

[0110] The configuration content (in JSON format) is as follows:

[0111]

[0112]

[0113] Furthermore, assume that after changing the rules, the client calls the interface of the field containing the @DynamicValid annotation through the Swagger document, and the request content is:

[0114]

[0115] Call method: POST / test / paramvalidate

[0116] Since the length of the userName does not meet the new rules (the length should be between 2 and 6 characters), the backend service returns the following response:

[0117]

[0118] Furthermore, the developer modifies the validation rules in Nacos again, for example, adjusting the length rule of the userName as follows:

[0119] Configuration details

[0120] - Namespace: sztb-yh-dev

[0121] - Data ID: spring-validate

[0122] - Group: DEFAULT_GROUP

[0123] The new configuration content is as follows:

[0124]

[0125]

[0126] Furthermore, call the same interface again. This time, the value of the userName field is still "Liang", but the length rule has changed to 1 - 6 characters, so the validation passes. The request content remains the same, still:

[0127]

[0128] Method: POST / test / paramvalidate

[0129] The backend service returns a response indicating that the validation is successful at this time, with the following content:

[0130]

[0131]

[0132] In summary, Nacos configuration changes are synchronized to the backend service in real time, without the need to restart or redeploy the application. By using Nacos configuration validation rules, the coupling between business logic and validation logic is significantly reduced, making rule modification more flexible. The use of custom validators and annotations has minimal impact on existing code structures, maintaining the developer's coding habits. Whether the validation is successful or not, the backend service returns a standardized JSON format response, which is easy for the front end to understand and process.

[0133] Figure 8 is a structural diagram of a data verification device according to an embodiment of the present application, as shown in Figure 8 , the device comprises:

[0134] The first acquisition module 82 is configured to acquire dynamic verification rules from a configuration center in a microservice architecture, wherein the dynamic verification rules at least include attribute fields of a business object; the dynamic verification rules are encapsulated into a rule information data structure, and the dynamic verification rules corresponding to the attribute fields of the business object are determined through the rule information data structure.

[0135] The second acquisition module 84 is configured to acquire a verifier set from a verifier framework, and establish a mapping relationship between the dynamic verification rules in the dynamic verification rule set and the verifiers in the verifier set.

[0136] The determination module 86 is configured to create a custom constraint verifier, rewrite a verification method of the custom constraint verifier, and determine a target dynamic verification rule set corresponding to a target attribute field of a target business object to be verified through the rule information data structure during execution of the verification method.

[0137] The verification module 88 is configured to determine a target verifier matching a target dynamic verification rule in the target dynamic verification rule set based on the mapping relationship, and verify the target attribute field through the target verifier.

[0138] Optionally, a mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set is established, and the method comprises the following steps: extracting a check rule name in the dynamic check rule; determining a data type corresponding to an attribute field of the business object; combining the check rule name and the data type into a joint key, searching for a validator matching the joint key in the validator set; and establishing the mapping relationship between the dynamic check rule in the dynamic check rule set and the validator in the validator set according to the search result.

[0139] Optionally, the target dynamic check rule set corresponding to the target attribute field of the target business object to be verified is determined through the rule information data structure, and the method comprises the following steps: obtaining a class full name to which the target business object belongs and a name of the target attribute field; taking the class full name and the name of the target attribute field as a joint query key, querying in the rule information data structure, and outputting the target dynamic check rule set obtained by the query.

[0140] Optionally, the target attribute field is checked by the target validator, and the method comprises the following steps: obtaining an actual value of the target attribute field from the target business object; and calling a check method of the target validator to check the actual value.

[0141] Optionally, after the target attribute field is checked by the target validator, the following steps can be further performed: determining whether the check result of the target validator is failure; in the case that the check result is failure, obtaining custom error information pre-bound with the target dynamic check rule; and setting the custom error information as final prompt information of the check, wherein the final prompt information is used to replace a default technical error message of the validator framework.

[0142] Optionally, in the global exception processing component, a method parameter invalid exception class generated due to the check failure is obtained; in the method parameter invalid exception class, the final prompt information is extracted; and a standardized error response body is generated according to the final prompt information.

[0143] Optionally, a custom constraint validator is created, and the method comprises the following steps: creating a validator implementation class; establishing a binding relationship between the validator implementation class and a custom validation annotation; and implementing validation logic declared by the custom validation annotation in the validator implementation class to obtain the custom constraint validator.

[0144] It should be noted that the above Figure 8 Each module can be a program module (for example, a program instruction set implementing a certain specific function) or a hardware module. For the latter, it can be in the form of a processor, or the functions of the above modules are implemented by a processor.

[0145] It should be noted that Figure 8 The preferred implementation of the embodiments shown can be seen in Figure 1 The relevant description of the embodiments shown, will not be repeated here.

[0146] Figure 9 A hardware structure block diagram of a computer terminal for implementing the data verification method is shown. As Figure 9 shown, the computer terminal 90 can include one or more (shown in the figure as 902a, 902b, …, 902n) processors 902 (the processor 902 can include but not limited to a microprocessor MCU or a programmable logic device FPGA processing device, etc.), a memory 904 for storing data, and a transmission module 906 for communication functions. In addition, it can also include a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art can understand that Figure 9 The structure shown is only schematic, which does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 90 can include more or less components than Figure 9 shown, or have a different configuration than Figure 9 shown.

[0147] It should be noted that the one or more processors 902 and / or other data processing circuits described above can be referred to herein generally as "data processing circuits". The data processing circuit can be embodied in whole or in part as software, hardware, firmware or any combination thereof. In addition, the data processing circuit can be a single independent processing module, or all or part of any one of the other elements combined into the computer terminal 90. As referred to in the embodiments of the present application, the data processing circuit as a kind of processor control (for example, the selection of variable resistance terminal path connected with the interface).

[0148] The memory 904 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the data verification method in the embodiments of the present application. The processor 902 executes various functional applications and data processing by running the software programs and modules stored in the memory 904, that is, implements the above-mentioned data verification method. The memory 904 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memories. In some examples, the memory 904 can further include a memory remotely arranged with respect to the processor 902, which can be connected to the computer terminal 90 through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0149] The transmission module 906 is configured to receive or send data via a network. The above-mentioned network examples can include a wireless network provided by a communication provider of the computer terminal 90. In one example, the transmission module 906 includes a network interface controller (NIC) which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 906 can be a radio frequency (RF) module which is configured to communicate with the Internet in a wireless manner.

[0150] The display can be, for example, a touch screen liquid crystal display (LCD) which can enable a user to interact with the user interface of the computer terminal 90.

[0151] It should be noted that, in some optional embodiments, the above-mentioned Figure 9 The computer terminal shown can include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that, Figure 9 is merely one example of a particular implementation and is intended to illustrate the types of components that can be present in the above-mentioned computer terminal.

[0152] It should be noted that, Figure 9 The computer terminal shown is configured to perform Figure 1 The data verification method shown, and thus the related explanations in the execution method of the above-mentioned commands also apply to the electronic device, which will not be described here again.

[0153] The embodiments of the present application also provide a non-volatile storage medium, which includes a stored program, wherein the program controls the device where the storage medium is located to execute the above-mentioned data verification method when running.

[0154] The non-volatile storage medium executes a program performing the following functions: obtaining dynamic check rules from a configuration center of a micro-service architecture, wherein the dynamic check rules at least include attribute fields of a business object; encapsulating the check rules into a rule information data structure, and determining a dynamic check rule set corresponding to the attribute fields of the business object through the rule information data structure; obtaining a validator set from a validator framework, and establishing a mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set; creating a custom constraint validator, rewriting a verification method of the custom constraint validator, and in the execution process of the verification method, determining a target dynamic check rule set corresponding to a target attribute field of a target business object to be verified through the rule information data structure; determining a target validator matching a target dynamic check rule in the target dynamic check rule set based on the mapping relationship, and verifying the target attribute field through the target validator.

[0155] The application further provides an electronic device, comprising a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program performs the data verification method.

[0156] The processor is configured to run a program performing the following functions: obtaining dynamic check rules from a configuration center of a micro-service architecture, wherein the dynamic check rules at least include attribute fields of a business object; encapsulating the check rules into a rule information data structure, and determining a dynamic check rule set corresponding to the attribute fields of the business object through the rule information data structure; obtaining a validator set from a validator framework, and establishing a mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set; creating a custom constraint validator, rewriting a verification method of the custom constraint validator, and in the execution process of the verification method, determining a target dynamic check rule set corresponding to a target attribute field of a target business object to be verified through the rule information data structure; determining a target validator matching a target dynamic check rule in the target dynamic check rule set based on the mapping relationship, and verifying the target attribute field through the target validator.

[0157] The above application embodiment serial numbers are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0158] In the above embodiments of the application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0159] In the above embodiments of the present application, the collected information is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, necessary protection measures are taken, the public order and good customs are not violated, and corresponding operation portals are provided for the user to select authorization or refusal.

[0160] In several embodiments provided in the present application, it should be understood that the disclosed technical content can be implemented by other ways. Among them, the above-described device embodiments are only schematic, for example, the division of the units can be a logical function division, and actual implementation can have another division way, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or modules shown or discussed can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.

[0161] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place or distributed to multiple units. Part or all of the units can be selected to achieve the purpose of the embodiment scheme according to actual needs.

[0162] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0163] The integrated unit, if realized in the form of software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application or the part that essentially contributes to the related art or the whole or part of the technical solutions can be embodied in the form of software product, which is stored in a storage medium and includes a plurality of instructions for making a computer device (which can be a personal computer, a server or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic or optical disk and various program code storage media.

[0164] The above merely describes the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, some improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements should also be considered as the protection scope of the present application.< / rule> < / rule>

Claims

1. A data checking method, characterized by, The method comprises the following steps: obtaining dynamic check rules from a configuration center of a micro-service architecture, wherein the dynamic check rules at least include attribute fields of a business object; encapsulating the dynamic check rules into a rule information data structure, and determining a dynamic check rule set corresponding to the attribute fields of the business object through the rule information data structure; obtaining a validator set from a validator framework, and establishing a mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set; creating a custom constraint validator, rewriting a verification method of the custom constraint validator, and determining a target dynamic check rule set corresponding to a target attribute field of a target business object to be verified through the rule information data structure during execution of the verification method; 2. The method of claim 1, wherein, based on the mapping relationship, determining a target validator matching a target dynamic check rule in the target dynamic check rule set, and verifying the target attribute field through the target validator. establishing the mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set comprises: extracting a check rule name in the dynamic check rule; determining a data type corresponding to the attribute field of the business object; combining the check rule name and the data type into a joint key, searching for a validator matching the joint key in the validator set; 3. The method of claim 1, wherein, according to the search result, establishing the mapping relationship between the dynamic check rules in the dynamic check rule set and the validators in the validator set. determining the target dynamic check rule set corresponding to the target attribute field of the target business object to be verified through the rule information data structure comprises: obtaining a class full name to which the target business object belongs and a name of the target attribute field; 4. The method of claim 1, wherein, using the class full name and the name of the target attribute field as a joint query key, querying in the rule information data structure, and outputting the target dynamic check rule set obtained by the query. verifying the target attribute field through the target validator comprises: obtaining an actual value of the target attribute field from the target business object; 5. The method of claim 1, wherein, calling a verification method of the target validator to verify the actual value. After verifying the target attribute field through the target validator, the method further comprises: determining whether the verification result of the target validator is failure; in the case that the verification result is failure, obtaining custom error information pre-bound with the target dynamic check rule; 6. The method of claim 5, wherein, setting the custom error information as final prompt information of verification, wherein the final prompt information is used to replace a default technical error message of a validator framework. The method further comprises: in a global exception handling component, obtaining a method parameter invalid exception class generated due to verification failure; in the method parameter invalid exception class, extracting the final prompt information; 7. The method of claim 1, wherein, generating a standardized error response body according to the final prompt information. creating a custom constraint validator comprises: creating a validator implementation class; binding the validator implementation class with the custom validation annotation; implementing the validation logic declared by the custom validation annotation in the validator implementation class to obtain a custom constraint validator.

8. A data checking apparatus, characterized by comprising: comprise: a first obtaining module, configured to obtain a dynamic check rule from a configuration center of a micro-service architecture, wherein the dynamic check rule at least includes a property field of a business object; encapsulate the dynamic check rule as a rule information data structure, and determine a dynamic check rule set corresponding to the property field of the business object through the rule information data structure; a second obtaining module, configured to obtain a validator set from a validator framework, and establish a mapping relationship between a dynamic check rule in the dynamic check rule set and a validator in the validator set; a determining module, configured to create a custom constraint validator, rewrite a validation method of the custom constraint validator, and determine a target dynamic check rule set corresponding to a target property field of a target business object to be verified through the rule information data structure in an execution process of the validation method; a checking module, configured to determine a target validator matched with a target dynamic check rule in the target dynamic check rule set based on the mapping relationship, and check the target property field through the target validator.

9. A non-volatile storage medium, comprising: The non-volatile storage medium comprises a stored program, wherein the program controls a device in which the non-volatile storage medium is located to perform the data check method in any one of claims 1 to 7 when the program is running.

10. An electronic device, comprising: comprise: a memory and a processor, wherein the processor is configured to run a program stored in the memory, and the program performs the data check method in any one of claims 1 to 7 when the program is running.

11. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the data check method in any one of claims 1 to 7.

Images