CN108345511B

CN108345511B - Application data checking method and device and electronic equipment

Info

Publication number: CN108345511B
Application number: CN201710053044.4A
Authority: CN
Inventors: 刘帅
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Singapore Holdings Pte Ltd
Priority date: 2017-01-24
Filing date: 2017-01-24
Publication date: 2022-02-08
Anticipated expiration: 2037-01-24
Also published as: CN108345511A

Abstract

The embodiment of the application discloses an application data checking method and device and electronic equipment. The method comprises the following steps: receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining data to be verified; acquiring a verification object matched with the data object, wherein the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified; calling the method of the verification object, and verifying the data object according to a corresponding verification rule; and returning the mark value of the verification result of the data object. According to the embodiments of the application, the data to be verified and the verification rule are abstracted, the data reading and the data source are isolated, the data reading logic is unified, and the problems that when the application program conducts local data verification, the data verification service logic is complicated and the realization code is difficult to maintain due to the uncertainty of the data generated in the operation process are solved.

Description

Application data checking method and device and electronic equipment

Technical Field

The application belongs to the technical field of data processing of terminal application development, and particularly relates to an application data verification method and device and electronic equipment.

Background

With the continuous development and expansion of services, the service fields related to terminal applications are more and more extensive at present, and more data are acquired and need to be processed. During the running process of the application program, some data which cannot be determined in advance is usually generated, such as input data of a user in a form, data which can be obtained only through calculation during the running process, and the like. Whether these locally generated data of the application comply with predetermined rules determines how the application should execute next. Therefore, at present, when an application program is designed and written, logic and a process for checking the data are required to be added. For example, in a typical example, the application presents a form for the user to fill in personal information, where the field requirement for the cell phone number is 11 digits 0-9 digits. If the input data of the user is verified and meets the requirement, the program normally executes the next process (such as skipping the next filling form or sending a verification code to the filled mobile phone number, etc.); otherwise, displaying error information to inform the user.

The current mainstream verification scheme is mainly divided into two steps: firstly, reading data to be checked; and secondly, judging whether each data to be checked conforms to the rule or not. However, with the continuous development and maintenance of applications, when new data to be verified or data verification rules need to be added, many disadvantages occur in the existing manner of reading each specific underlying service data and performing verification by using the rules of the underlying service data. For example, different sources of data to be verified have different reading modes, and when a new source of data to be verified is added, the code logic for reading the data needs to be added accordingly. Therefore, in the existing scheme, the data reading step is weak in expandability and not flexible enough, and the logic of data reading cannot be uniformly processed. Moreover, the data verification rules may change as the business progresses. If the mobile phone number input by the user is verified, the initial rule is "11 digits 0-9 digits", and later the rule is added to "11 digits 0-9 digits and starts with the number 1". When the existing scheme is used for processing the situation, a branch logic needs to be added in the data verification process to judge whether the read data meets the added rule or not. For example, the exemplary pseudo-code is as follows:

DEFINE Mobile number; // data to be checked

if (mobile number is not an Arabic number from bits 11, 0-9) return fails;

// Branch logic with newly added rule check below

if (mobile number does not start with 1) return fails;

return was successful;

in the method for local data verification in the prior art, due to the fact that the data to be verified from different sources have different reading logics and verification rules and may change along with the development of services, each service data needs corresponding verification logics, the logic for data reading cannot be processed uniformly, and the data reading and verification part is weak in expansibility and not flexible enough. Meanwhile, different data have different check rules, which means that the check rules are more and complicated, and the data check is more complex to process. By using the existing scheme, the data to be verified and the corresponding verification rules cannot be organized and managed orderly, the reusability of the code for data verification is poor, and the data verification execution and management efficiency is low.

Disclosure of Invention

The application aims to provide an application data verification method, an application data verification device and electronic equipment, wherein local data to be verified and verification rules are abstracted, data reading and data source are isolated, data reading logic is unified, and the problems that data verification business logic is complicated and realization codes are difficult to maintain due to uncertainty of data generated during operation when an application program conducts local data verification are solved.

The application data verification method, device and electronic equipment provided by the application data verification method are realized as follows:

a method of application data verification, the method comprising:

receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining data to be verified;

acquiring a verification object matched with the data object, wherein the verification object comprises data to be verified and at least one verification rule of the data to be verified, which are constructed in advance;

calling the method of the verification object, and verifying the data object according to a corresponding verification rule;

and returning the mark value of the verification result of the data object.

An application data verification apparatus, the apparatus comprising:

the data acquisition module is used for receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining the data to be verified;

the matching module is used for constructing and storing a verification object matched with the data object, and the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified;

the verification module is used for calling the method of the verification object and verifying the data object according to the corresponding verification rule;

and the result returning module is used for returning the mark value of the verification result of the data object.

An electronic device comprising a processor and a memory for storing processor-executable instructions,

the processor is configured to receive a verification request for a data object, the data object conforming to prescribed data characteristics defining data to be verified; the verification object is also used for acquiring a verification object matched with the data object, and the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified; the method is also used for calling the verification object and verifying the data object according to the corresponding verification rule; and the flag value is also used for returning the verification result of the data object.

A method of implementing local data verification, comprising:

storing data to be verified registered with the key value pair and a verification rule met by the data to be verified in a data format of the key value pair, wherein the data to be verified in the key value pair is a key, and a verification entity corresponding to the data to be verified is a value; the verification entity is generated by carrying out data encapsulation on registered data to be verified and corresponding verification rules;

when local data to be verified generated by application is received, acquiring a verification object matched with the local data to be verified from the dictionary database according to the specified data characteristics of the local data to be verified;

and calling the method of the verification object, verifying the local data to be verified according to the corresponding verification rule, and returning a mark value of a verification result.

According to the application data verification method, the application data verification device and the electronic equipment, data to be verified and verification rules are abstracted, characteristics of the data and the rules are defined, conventional complex and changeable business data to be verified are abstracted into data with specified characteristics, the verification rules and the verification process are logically packaged into a verification entity, specific data and specific rules are not concerned any more, data reading and data sources are isolated, and the data to be verified and the corresponding verification rules are orderly organized and managed. In the embodiment of the application, the data to be verified and the verification rules can be uniformly defined in advance in an abstract mode, the data and the rules are uniformly managed in a specified data format mode, and the judgment logic is collected into the verified target verification object. When the scheme is used, the data to be verified and the corresponding verification rule can be registered in advance, and a method for returning and calling is defined and used for receiving the verification result. After the registration is finished, a verification entity and a verification method can be called through an exposed interface when data verification is carried out. Then, the return value is checked to know whether the data accords with the check rule or not, and the data check is completed. By utilizing the embodiment of the application, the given data to be verified can conveniently and efficiently inquire and modify the verification rules of the data to be verified, the addition and deletion of the verification rules are facilitated, the data to be verified and the corresponding verification rules are orderly organized and managed, the reading logic of the verification data is unified, the application verification operation flow becomes clear and controllable, the management efficiency of the execution of the data verification and the data to be verified and the verification rules of the data to be verified can be effectively improved, and the expansibility of the data verification and the convenience of management and maintenance are greatly improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.

FIG. 1 is a flowchart of an embodiment of a method for verifying application data provided herein;

FIG. 2 is a schematic class diagram of a specific checking entity class provided herein;

FIG. 3 is a schematic class diagram of a custom dictionary class that holds the mapping concerns of data to be verified to verification entities in an embodiment of the present application;

FIG. 4 is a schematic structural diagram of a custom dictionary used in data verification using a verification device according to the present application;

FIG. 5 is an overall schematic class diagram of the management portion of custom dictionary class data and rules in one embodiment of the present application;

FIG. 6 is a schematic flow chart illustrating a process for verifying data using the method of the present application;

FIG. 7 is a block diagram of an embodiment of an application data verification apparatus according to the present application;

FIG. 8 is a schematic block diagram of another embodiment of the apparatus provided herein;

fig. 9 is a schematic diagram of a scenario in which local data filled by a user at a client is checked in an exemplary scenario of the present application.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Fig. 1 is a flowchart of an embodiment of a method for verifying application data according to the present application. Although the present application provides the method operation steps or apparatus structures as shown in the following embodiments or figures, more or less operation steps or module units after partial combination may be included in the method or apparatus based on conventional or non-inventive labor. In the case of steps or structures which do not logically have the necessary cause and effect relationship, the execution sequence of the steps or the module structure of the apparatus is not limited to the execution sequence or the module structure shown in the embodiment or the drawings of the present application. When the described method or module structure is applied to a practical device or an end product, the method or module structure according to the embodiment or the figures may be executed sequentially or executed in parallel (for example, in the environment of parallel processors or multi-thread processing, or even in the environment of distributed processing).

For clarity, a specific mobile terminal application is used to verify data input by a user on a page as an application scenario. However, those skilled in the art will appreciate that the spirit of the present solution may be applied to other implementation scenarios of local data verification generated when verification-dependent applications, terminal devices, systems, etc. are run. It should be understood that "local" implementing local data verification is generally understood in one example that the application in the terminal device does not have to communicate data with other programs in any form, or rely on other programs in any form, or by other programs. The runtime may refer to a context in the process of running the program, including but not limited to data, variables, code, environment, and the like in the process of running the program. Through the implementation mode provided by the application, the data to be checked and the checking rule characteristics are uniformly defined in an abstract mode, the condition that (realization) objects with specified characteristics of the abstract data to be checked can read the data by using built-in data reading logic so as to perform subsequent data checking is met, the data and the rules are uniformly managed in a self-defined dictionary mode, the judgment logic is collected into the checking entity object to package the checking process into the checking entity class, the checking logic is multiplexed, the external checking result can be informed in a mode of exposing a callback interface, the complexity of checking different business data at the bottom layer is stripped, the data checking logic is uniform and clearly controllable, and the expansibility, the management and the maintenance of the data checking are greatly improved. The extensibility is the ability to add new logic or delete old logic without modifying the original system architecture and the original implementation logic in a large scale.

Specifically, as shown in fig. 1, in an embodiment of the application data verification method provided by the present application, the method may include:

s1: receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining the data to be verified.

The data object described in the embodiment of the present application may be defined to conform to a rule data characteristic that needs to be satisfied when defining the data to be verified. The data to be checked in this embodiment may be abstracted as "any object that can provide data of a string type", or even generalized as "any object that can provide an arbitrary instance". In actual processing, according to which specified data characteristics need to be satisfied by a data object of a service needing to be verified, data meeting the specified data characteristics can be defined as data to be verified in a unified manner. The characteristics of the data to be verified are specified, and in different service scenes, it can be defined and set that all the data having (meeting) the characteristics of the rule data can be verified in the embodiment of the application. Therefore, when a new data to be verified is added, the data can meet the specified conditions through simple modification, and the data reading method built in the application can be utilized to finish the data reading uniformly. The data reading and the data source can be isolated by the mode, the data reading does not concern the data source any more, and the logic is unified.

Taking Objective-C programming language as an example, the following interface can be defined to specify the characteristics of the data to be verified.

@protocol AEValidatable<NSObject>

@required

-(NSString*)validationText；

@end

The above is a schematic description of a programming language for the features of data to be verified. The @ required line indicates that if an object claims itself to satisfy the present feature, it must implement the method defined by the next line. The line- (NSString) validationText is a feature ontology. That is, if an object implements this method, returning a variable of the NSString type, it satisfies the feature. @ protocol AEValidatable < NSObject > defines the name of the feature of the data to be checked, AEValidate. That is, all objects satisfying (realizing) the characteristics specified by the interface can read data by using the data reading logic built in the system, and then perform subsequent data verification. In a specific implementation, the interface is defined, and the characteristics of the data to be verified are defined, and the process of defining the characteristics of the data is implemented in a specific programming language, that is, an interface is defined as described above.

That is, in all the examples of the class in which the interface is implemented, the unified system built-in data reading logic can be used to read the data to be verified, and then the subsequent verification is performed. For example, the TextField class implements this interface, returning its text content, and its instance can be checked in the application implementing the present solution.

In this particular example, UITextField asserts that it satisfies the AEValidatable by itself. It realizes the method specified by the feature ontology and returns a string variable (self), so that the data object using the TextField class can be checked in the application implementing the scheme, such as mobile terminal application.

As can be understood from the above description, the data object initiating the verification request according to the embodiment of the present application is also a specified data feature that meets the requirement of the abstract data to be verified. In a specific application scenario, the data object is a verified object, such as a text box, that conforms to the regular data characteristics of the data to be verified. It is specified at the initial registration which rules the content in the data object of this text box needs to satisfy. And when the verification is initiated, the text box is used as a data object to be verified.

S2: and acquiring a verification object matched with the data object, wherein the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified.

In this embodiment, to manage the data to be verified and the corresponding verification rule, a verification object may be defined. The verification object can hold data to be verified and a verification rule which is expected to be satisfied by the data to be verified. The rules may be understood as predefined conditions, characteristics, features. Of course, the check rule may include one or more check rules. In an embodiment provided by the present application, the verification object may adopt a defined verification entity class, and the registered data to be verified and at least one verification rule are stored in the verification entity class. Here, the verification rule may also be abstracted as an object that receives data to be verified and returns a variable value identifying whether the data form rule is satisfied. Of course, this application does not exclude other embodiments that do not use a calibration entity class, do not encapsulate the calibration process, and place the implementation of the calibration process in the calibration execution body, such as the calibrator. In a specific embodiment, the verification object may include:

s201: the verification entity is generated by carrying out data encapsulation on registered data to be verified and corresponding verification rules, the registered data to be verified is defined as an object of data meeting specified data characteristics, and the verification rules are defined as an object for receiving the data to be verified and returning variable values for identifying whether the variable values meet data form rules or not.

In one specific example, a check rule may be abstracted as "an object that receives a string and returns a boolean value that identifies whether the rule is satisfied. Still taking Objective-C language as an example, the following interface can be defined, specifying the characteristics of the verification rule:

@protocol AEValidationRule<NSObject>

-(BOOL)validate:(NSString*)text；

-(NSString*)errorMessage；

@end

then whatever instance of the class implementing the above interface may be used as a verification rule for the mobile terminal application. For example, the check rule may be: the length of the data must be 11, if it is satisfied, the check is passed, otherwise, the check is not passed. This rule is implemented as follows:

of course, references to "verification rules" in this application refer to abstract verification rules. Fig. 2 is a schematic class diagram of a specific checking entity class provided in the present application.

Further, in another embodiment provided by the present application, a dictionary may be used to store a mapping between data to be verified and a verification rule thereof. The dictionary is a data structure, a pair of keys and values are stored, and the corresponding values can be found within constant complexity through the given keys. In another embodiment of the application, the custom dictionary can be used as a managed container to store the mapping from the data to be verified to the verification entity class, so that the verification rule of the given data to be verified can be conveniently searched through the exposed interface. FIG. 3 is a schematic class diagram of a custom dictionary class that holds the mapping concerns of data to be verified to verification entities in an embodiment of the present application. In a specific embodiment, the obtaining of the verification object matched with the data object may include:

s202: taking the data object as a query key, and acquiring keys with the same value and corresponding values of the query key from a key value pair stored in a user-defined dictionary;

the user-defined dictionary is set to store data to be verified registered with the user-defined dictionary and verification rules met by the data to be verified in a key value pair data format, wherein the data to be verified in the key value pair is a key, and a verification entity corresponding to the data to be verified is a value.

For example, after determining the data D to be verified and the verification rules thereof, the verification rules are placed in a list, such as [ a, B, … ], the verification rules A, B defining the data D to be verified are defined in the list, and so on. The data D to be verified and the list of verification rules a, B, … may then be encapsulated into a verification object E (i.e., the described verification entity class). The key in the self-defined dictionary is D, and the value is E. Fig. 4 is a schematic structural diagram of a custom dictionary used in data verification using a verification device according to the present application. Generally, a self-defined dictionary is arranged in a checker, and the checker and the self-defined dictionary can be in a one-to-one correspondence relationship. A verifier supports verification of all data objects that satisfy a specified data characteristic. (it is enough to register the data objects of different services and the corresponding check rule lists in the custom dictionary in advance). Of course, it is not per se excluded that in some embodiments, different service domains use separate checker objects, which is better maintainability.

FIG. 5 is an overall schematic class diagram of the management portion of custom dictionary class data and rules in one embodiment of the present application. By adopting a method of self-defining a dictionary, abstract data to be verified is used as a key, a verification entity is used as a value, unified management and storage are realized, and a user adds data and rules in a registration mode. Specifically, in an embodiment, when it is determined that the check of the new service data object is added, the new service data object and the corresponding check rule are registered in the custom dictionary, and a key value pair is generated with the new service data object as a key and a check entity generated by packaging the new service data object and the corresponding check rule as a value.

In a specific example, when the mobile phone number input by the user is verified as described above, the rule is "11 digits 0 to 9 digits", and the rule is added to "11 digits 0 to 9 digits and starts with the digit 1". When the embodiment is used for processing the condition that the check rule is increased, the branch logic is not required to be added, and the newly added rule is only required to be registered to the mobile terminal for application, so that the rule is increased. The manner of rule reduction is similar. Therefore, the data checking part can flexibly add and delete the checking rules, and the expansibility of the system is improved. The pseudo code is as follows.

DEFINE Mobile number; // data to be checked

DEFINE validator; v/checker object provided by the present System

Register (mobile number, forRules: [ 11-bit 0-9 Arabic numerals, beginning with numeral 1 ])

return validator.validate()

The original scheme is that the rule is changed from 'A' to 'A and B', and 'whether A is satisfied, whether B is satisfied' is required, so that the judgment logic is realized by the user; the rule of the scheme is changed from a list [ A ] with only one element A into a list [ A, B ] composed of two elements, and the list is maintained in the system and is transparent to a user. The user can complete logic addition only by registering the addition rule B through the API exposed by the system. The same applies to rule deletion. Therefore, a user can directly register by using a new rule without knowing the logic of the original verification rule, so that the whole verification management is efficient, simple and easy to expand.

S3: and calling the method of the verification object, and verifying the data object according to the corresponding verification rule.

When data verification is carried out in practical application, a verifier can be provided, and a self-defined dictionary instance is arranged in the verifier. And calling an exposed interface of the verifier from the outside, and registering the verification rule met by the data to be verified and the expected data to the verifier. The checker internally utilizes the two to generate a checking entity, and stores the data and the corresponding checking entity in the self-defined dictionary instance in the form of key values. The verifier may also provide an interface for de-registration to cancel verification of certain data. The verification result of the verifier can be notified to the outside by calling a callback method, and the callback method is specified by the outside.

When the data object is checked, the keys and the values can be taken out from the dictionary in sequence, the checking method of the checking entity is called, the return value is checked, and whether the data accords with the checking rule or not can be known.

S4: and returning the mark value of the verification result of the data object.

As described above, after the verification is completed, the verification result of the data object can be obtained, and in this embodiment, because the processing of the abstract data class of the verification data and the verification rule thereof is adopted, a flag value indicating the verification result of the data object can be set to be returned. For example, a flag variable may be set inside the checker to identify the check result, and the check result may be obtained externally by checking the value of the flag variable.

In an embodiment provided by the application, the external verification result can be notified in a callback mode. Specifically, in an embodiment provided by the present application, the returning the flag value of the verification result of the data object may include:

s401: and returning the verification result of the data object to the verification request initiator in a method call-back mode.

And packaging the verification process into a verification entity class, reusing the verified logic, and informing an external verification result by the system in a mode of exposing a callback interface. In one embodiment, the returned check result may be a boolean value that identifies whether the check rule is satisfied.

In the foregoing, one type of data to be verified may include one or more verification rules. The verification rule is abstracted and can be packaged into a verification entity. In the application data verification method provided by the application, the verification rules in the verification entity are stored in a verification rule list, and at least one verification rule of the data to be verified is reserved in the verification rule list.

The method uses a check rule list to store and define the check rule of the data to be checked, can improve the management of the check rule, and is convenient for operations such as addition, deletion and the like. Thus, the method further comprises:

when a first verification rule added with data to be verified is confirmed, registering the first verification rule into a verification rule list corresponding to the data to be verified in the self-defined dictionary;

when a second check rule for deleting the data to be checked is confirmed, deleting the second check rule from a check rule list corresponding to the data to be checked;

and when the third verification rule for modifying the data to be verified is confirmed, replacing the modified third verification rule with the original third verification rule in the verification rule list corresponding to the data to be verified.

In addition, in another embodiment of the present application, the verification entity may further encapsulate a verification logic of the data to be verified; correspondingly, the invoking of the check rule in the check object to check the data object includes determining, according to the check logic, a check execution mode of using the check rule to check the data object. For example, it is checked in turn whether the data satisfies each rule in the rule list.

Fig. 6 is a schematic processing flow chart of data verification by the method of the present application. According to the scheme provided by the application, the data to be verified and the verification rules are uniformly defined in advance in an abstract mode, the data and the rules are uniformly managed in a specified data format mode, and the judgment logic is collected into the verified target verification object. When the scheme is used, the data to be verified and the corresponding verification rule can be registered in advance, and the callback method is used for receiving the verification result. After the registration is finished, a verification entity and a verification method can be called through an exposed interface when data verification is carried out. Then, the return value is checked to know whether the data accords with the check rule or not, and the data check is completed. By utilizing the embodiment of the application, the given data to be verified can conveniently and efficiently inquire and modify the verification rules of the data to be verified, the addition and deletion of the verification rules are facilitated, the data to be verified and the corresponding verification rules are orderly organized and managed, the reading logic of the verification data is unified, the application verification operation flow becomes clear and controllable, the management efficiency of the execution of the data verification and the data to be verified and the verification rules of the data to be verified can be effectively improved, and the expansibility of the data verification and the convenience of management and maintenance are greatly improved.

Based on the application data verification method described in the above embodiment or scenario, the present application further provides an application data verification apparatus. The apparatus can include systems (including distributed systems), software (applications), modules, components, servers, etc. that employ the methods described herein, in conjunction with hardware where necessary to implement the apparatus. Based on the same innovative concept, the device in one embodiment provided by the present application is described in the following embodiment. Because the implementation scheme of the device for solving the problems is similar to that of the method, the implementation of the specific device in the present application can refer to the implementation of the method, and repeated details are not repeated. As used hereinafter, the term "unit" or "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated. Fig. 7 is a schematic block diagram of an embodiment of an application data verification apparatus provided in the present application, and as shown in fig. 7, the apparatus may include:

the data acquisition module 101 may be configured to receive a verification request for a data object, where the data object conforms to a specified data characteristic defining data to be verified;

the matching module 102 may be configured to construct and store a verification object matched with the data object, where the verification object includes pre-constructed data to be verified and at least one verification rule of the data to be verified;

the verification module 103 may be configured to invoke a method of the verification object, and verify the data object according to a corresponding verification rule;

the result returning module 104 may be configured to return a flag value of the verification result of the data object.

In an embodiment of the apparatus of the present application, the data object may be an implementation of a checking entity, and thus. In one embodiment, the verification object may include:

the verification entity is generated by carrying out data encapsulation on registered data to be verified and corresponding verification rules, the registered data to be verified is defined as an object of data meeting specified data characteristics, and the verification rules are defined as an object for receiving the data to be verified and returning variable values for identifying whether the variable values meet data form rules or not.

In another embodiment of the device, the device may be used for storing the mapping relationship between the data to be verified and the verification rule thereof in a dictionary. Fig. 8 is a schematic block diagram of another embodiment of the apparatus provided in the present application, and as shown in fig. 8, the apparatus may further include:

the custom dictionary 105 may be configured to store data to be verified registered therewith and a verification rule that the data to be verified satisfies in a data format of a key value pair, where the data to be verified in the key value pair is a key and a verification entity corresponding to the data to be verified is a value;

correspondingly, the step of obtaining the verification object matched with the data object by the matching module 102 includes obtaining a verification entity having the same value as the data key to be verified from the custom dictionary 105.

In another embodiment, the checking entity further encapsulates checking logic of the data to be checked;

correspondingly, the method for calling the verification object by the verification module 103 to verify the data object according to the corresponding verification rule includes determining a verification execution mode for the data object by using the verification rule according to the verification logic.

In another embodiment of the apparatus, the returning the flag value of the verification result of the data object by the result returning module 104 includes:

and returning the Boolean value for identifying whether the data object meets the verification rule to the verification request initiator in a method call-back mode.

The specific implementation of the apparatus according to the above embodiments may refer to the description of the related contents of the foregoing method embodiments. The different embodiments are mainly described in the differences from the other embodiments, and the same or similar embodiments may be referred to each other, which is not repeated herein.

The method or apparatus described in this application can be implemented in the form of a checker, which can implement the business logic described above in this application using a certain programming language such as Objective-C. Generally, a verifier instance has a custom dictionary instance, which supports storing multiple kinds of verification data (conforming to the predetermined characteristics), and in practice, a verifier object is implemented to store all data to be verified in a certain service domain. For example, the data to be verified in the text box a, the data to be verified in the text box B, and the data to be verified in the multi-box C may be simultaneously stored.

The verifier implemented in the present application may call method M1, for example, M1(a), to inform the verifier to verify only the data of text box a, or call method M2 to verify all the registered data — A, B, C, specifically determined according to the user's needs, and the verifier has this capability.

When the user uses, what the call is that the calibrator exposes to user's interface (API), the inside realization of calibrator is transparent to the user, and the user can not need directly to make a traffic with calibration entity or self-defined dictionary object, can only need to register data and rule. When needed, calling the API to initiate a verification process, and receiving a verification result, standing at the angle of a user, wherein the verifier is a black box.

The technical scheme of the application can be realized by object-oriented programming languages, such as Objective-C language.

Of course, in other embodiments of the apparatus or method, the checking entity class may not be used, the checking process is not encapsulated, and the implementation of the checking process may be placed in the checker. Even in other embodiments, the management of the data to be verified may not use a dictionary (i.e., does not store the mapping relationship between the data and the rule), does not use data types such as Map and Table, and only uses one List to store the verification entity. The check result of the checker can be realized in a mode that a flag variable is set inside the checker to identify the check result without using callback mode notification, and the check result is obtained by checking the value of the variable from the outside. Other embodiments based on the innovative concepts of the present application are intended to be within the scope of the present application.

The application data verification device provided by the application data verification method can define data to be verified and verification rules in an abstract mode in advance, manage the data and the rules in a unified mode through a specified data format mode, and collect judgment logic into a verified target verification object. When the scheme is used, the data to be verified and the corresponding verification rule can be registered in advance, and a method for returning and calling is defined and used for receiving the verification result. After the registration is finished, a verification entity and a verification method can be called through an exposed interface when data verification is carried out. Then, the return value is checked to know whether the data accords with the check rule or not, and the data check is completed. By utilizing the embodiment of the application, the given data to be verified can conveniently and efficiently inquire and modify the verification rules of the data to be verified, the addition and deletion of the verification rules are facilitated, the data to be verified and the corresponding verification rules are orderly organized and managed, the reading logic of the verification data is unified, the application verification operation flow becomes clear and controllable, the management efficiency of the execution of the data verification and the data to be verified and the verification rules of the data to be verified can be effectively improved, and the expansibility of the data verification and the convenience of management and maintenance are greatly improved.

The application data verification method or the application data verification device can be applied to various terminal applications or server systems, and effectively solves the problems of complex data verification business logic, difficult code maintenance and the like caused by uncertainty of data generated during operation during local data verification. The present application thus also provides an electronic device, which may include a mobile terminal (e.g., a cell phone), a PC, a server, a distributed system, etc., comprising a processor and a memory for storing processor-executable instructions,

the processor is configured to receive a verification request for a data object, the data object conforming to a prescribed data characteristic defining data to be verified; the verification object is also used for acquiring a verification object matched with the data object, and the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified; the method is also used for calling the verification object and verifying the data object according to the corresponding verification rule; and the flag value is also used for returning the verification result of the data object.

In another embodiment, the electronic device may further include a storage unit, coupled to the processor, configured to store, in a data format of a key value pair, data to be verified registered therewith and a verification rule that the data to be verified satisfies, where the key value pair is a key for the data to be verified and a verification entity corresponding to the data to be verified is a value;

correspondingly, the processor acquires the verification object matched with the data object and performs verification, wherein the verification comprises acquiring data of a verification entity with the same value as the data key to be verified from the self-defined dictionary, and completing data verification in the verification entity.

Of course, the electronic device may also have other embodiments with reference to the description of the foregoing method or apparatus embodiments, and may specifically refer to the description of the foregoing method or apparatus, which is not described herein again.

The method or the device can be applied to the client side and the server side, and the client side or the server side independently realizes the functions of the method or the device to realize the verification of the client side or the server on the local data. Alternatively, the present application does not exclude that in some embodiments, some steps are implemented by the server side, for example, in the implementation process of obtaining the verification object matched with the data object, the server side may store the dictionary, then match the verification object according to the verification request and implement the verification, and finally send the verification result to the client side. In other implementation scenarios of the application data verification method provided by the present application, the obtained data object to be verified may be local data of the client, for example, local data generated by a user filling a mobile phone number in a form during a certain application running process in a mobile terminal. The processing procedure of checking the local data of the mobile phone number, for example, including obtaining the check object, performing the check according to the corresponding check rule, returning the value of whether the check passes or not, and the like, described in the foregoing embodiment, may be implemented in the local terminal, and may not need to interact with the server side in the processing procedure of the local data check. Specifically, the present application further provides a method for implementing local data verification, which specifically includes:

The method for achieving local data verification provided by the embodiment of the application can store a plurality of pre-designed verification entities aiming at different data to be verified, and the mapping relation between the verification entities and the corresponding data to be verified can be stored in a database of a client. The keys and values corresponding to the data to be verified can be taken out from the dictionary database through the exposed interface of the dictionary database, then the verification method of the verification entity is called, the verification is carried out, the value of the verification result is returned, and whether the data generated by the client application accords with the verification rule or not can be obtained. Of course, the method for realizing local data verification can also be used for other terminal devices, such as a server, an intelligent wearable device, a vehicle-mounted system and the like, and the local data can be verified by the terminal devices.

Fig. 9 is a schematic diagram of a scenario in which local data filled by a user at a client is checked in an exemplary scenario of the present application. As shown in fig. 9, the user fills in a plurality of service data in a form in one registered service item of the application. If the conventional method is adopted, the name is usually checked to be in accordance with the requirement by checking the rule that the interface of the name text box calls the name, and the rule 1 that the interface of the telephone text box calls the telephone is checked: the '11 bit 0-9 Arabic numerals' are used for verifying whether the telephone filling meets the requirements or not. If other services are added, such as password modification service items, the code logic of the data is correspondingly added when the source data to be verified is added, and a calling interface of the password modification service for verifying the input data is set. In the existing scheme, the data reading step has weak expandability and is not flexible enough, and the logic of data reading cannot be uniformly processed. By adopting the scheme of the embodiment of the application, the data to be verified is abstracted, the characteristics of the data to be verified are specified, namely, all the data with certain characteristics can be verified. Therefore, when newly adding a new data to be verified, the data can be uniformly read by using the built-in data reading method provided by the application as long as the data meets the specified conditions through simple modification. The data reading and the data source can be isolated by the mode, the data reading does not concern the data source any more, and the logic is unified. For example, in the scenario shown in fig. 9, a dynamic registration rule may be implemented, so as to flexibly and conveniently pre-register and manage various data to be verified. When various data to be verified (names and telephone numbers in the form) are verified, the corresponding verification entity class can be called to complete verification. If the rules change, e.g., add phone rule 2: "11 digits 0-9 digits and beginning with the number 1," then the rule 2 can be directly registered in the dictionary, and of course, the original rule 1 can be deleted directly.

The complexity of data verification is represented by many and complicated verification rules. By using the existing scheme, the data to be verified and the corresponding verification rules cannot be organized and managed orderly. The technical scheme provided by the embodiment of the application can use a self-defined dictionary mode, abstract data to be verified is used as a key, a self-defined verification entity encapsulating a verification process is used as a value, and a verification rule list is stored in the verification entity class, so that the verification rules of the given data to be verified can be conveniently and efficiently inquired, and the addition and deletion of the verification rules are facilitated.

Although the present application refers to the descriptions of data definition, matching, interaction, calculation, judgment, etc. such as callback mode feedback of verification result, dictionary management verification data, package verification process using verification entity class, implementation of customized dictionary using Objective-C programming language, etc., the present application is not limited to the case that the description is necessarily in accordance with the intra-industry data communication identifier, standard component tool call, standard computer language processing/database storage loading method, or the description of the embodiments of the present application. Certain industry standards, or implementations modified slightly from those described using custom modes or examples, may also achieve the same, equivalent, or similar, or other, contemplated implementations of the above-described examples. The embodiments obtained by applying the modified or transformed configuration data definition, storage, judgment, setting mode, etc. may still fall within the scope of the alternative embodiments of the present application.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The apparatuses, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or implemented by an article with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although the present application provides method steps as described in an embodiment or flowchart, more or fewer steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded.

For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, in implementing the present application, the functions of each module may be implemented in one or more software and/or hardware, or a module implementing the same function may be implemented by a combination of a plurality of sub-modules or sub-units, and the like. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may therefore be considered as a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. An application data verification method, the method comprising:

receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining data to be verified; the data to be verified refers to an object of data meeting specified data characteristics;

verifying the data object by using the specified data characteristics which are allegedly met by the data object, and reading the data in the data object by using the data reading logic built in the system under the condition that the data object is confirmed to meet the specified data characteristics;

acquiring a verification object matched with the data object, wherein the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified;

calling the verification object, and verifying the read data in the data object according to a corresponding verification rule;

and returning the mark value of the verification result of the data object.

2. The method for verifying application data of claim 1, wherein the verification object comprises:

and the verification rule is defined as an object which receives the data to be verified and returns a variable value for identifying whether the variable value conforms to the data form rule.

3. The method as claimed in claim 2, wherein said obtaining a verification object matching said data object comprises:

taking the data object as a query key, and acquiring keys with the same value and corresponding values of the query key from a key value pair stored in a user-defined dictionary;

4. The method according to claim 3, wherein when it is determined to add a new service data object for verification, the new service data object and the corresponding verification rule are registered in the custom dictionary, and a key-value pair is generated with the new service data object as a key and a verification entity generated by encapsulating the new service data object and the corresponding verification rule as a value.

5. A method as claimed in claim 3, wherein the checking rules in the checking entity are stored in a checking rule list, and at least one checking rule of the data to be checked is reserved in the checking rule list.

6. The method of claim 5, wherein the method further comprises performing at least one of:

7. The method for verifying application data of claim 5, wherein the verifying entity further encapsulates a verifying logic for setting the data to be verified;

correspondingly, the invoking the verification object and verifying the data object according to the corresponding verification rule includes: and determining a verification execution mode of the data object by using the verification rule according to the verification logic.

8. The method as claimed in claim 1, wherein said returning the flag value of the verification result of the data object comprises:

and returning the verification result of the data object to the verification request initiator in a method call-back mode.

9. The method as claimed in claim 8, wherein the returned verification result is a boolean value identifying whether the verification rule is satisfied.

10. An application data verification apparatus, comprising:

the data acquisition module is used for receiving a verification request of a data object, wherein the data object conforms to the specified data characteristics defining the data to be verified; the data to be verified refers to an object of data meeting specified data characteristics; verifying the data object by using the specified data characteristics which are allegedly met by the data object, and reading the content in the data object by using the data reading logic built in the system under the condition that the data object is confirmed to meet the specified data characteristics;

the verification module is used for calling the verification object and verifying the read data in the data object according to a corresponding verification rule;

11. The application data checking apparatus of claim 10, wherein the check object comprises:

12. The application data checking apparatus as claimed in claim 11, wherein the apparatus further comprises:

the self-defined dictionary is used for storing data to be verified registered with the self-defined dictionary and verification rules met by the data to be verified in a key value pair data format, wherein the data to be verified in the key value pair is a key, and a verification entity corresponding to the data to be verified is a value;

correspondingly, the step of acquiring the verification object matched with the data object by the matching module comprises the step of acquiring a verification entity with the same value as the data key to be verified from the self-defined dictionary.

13. The apparatus for verifying application data of claim 11, wherein the verifying entity further encapsulates a verifying logic of the data to be verified;

correspondingly, the check module is used for determining a check execution mode of the data object by using the check rule according to the check logic.

14. The application data checking apparatus of claim 13, wherein the result returning module returns the flag value of the checking result of the data object includes:

15. An electronic device comprising a processor and a memory for storing processor-executable instructions,

the processor is configured to receive a verification request for a data object, the data object conforming to prescribed data characteristics defining data to be verified; the data to be verified refers to an object of data meeting specified data characteristics; verifying the data object by using the specified data characteristics which are allegedly met by the data object, and reading the content in the data object by using the data reading logic built in the system under the condition that the data object is confirmed to meet the specified data characteristics; the verification object is also used for acquiring a verification object matched with the data object, and the verification object comprises pre-constructed data to be verified and at least one verification rule of the data to be verified; the method is also used for calling the verification object and verifying the read data in the data object according to a corresponding verification rule; and the flag value is also used for returning the verification result of the data object.

16. An electronic device as recited in claim 15, wherein said electronic device further comprises:

the storage unit is coupled with the processor and used for storing the data to be verified registered with the storage unit and the verification rule met by the data to be verified in a key-value pair data format to form a self-defined dictionary; the data to be verified in the key value pair is a key, and a verification entity corresponding to the data to be verified is a value;

correspondingly, the step of acquiring and verifying the verification object matched with the data object by the processor comprises the following steps: and acquiring the data of the verification entity with the same value as the data key to be verified from the custom dictionary, and completing data verification in the verification entity.

17. A method for implementing local data verification, comprising:

when local data to be verified generated by application is received, the local data to be verified conforms to the specified data characteristics, and a verification object matched with the local data to be verified is obtained from a dictionary database;

and calling the verification object, verifying the local data to be verified according to the corresponding verification rule, and returning a mark value of a verification result.