Microsoft enterprise database 5.0 learning path-Step 5: Introduction to entlib. validation module information, implementation level of validators, and use of various built-in validators-Part 1

This article paves the way for later learning. It briefly introduces some related knowledge about the validation module in the enterprise database, it includes the description, purpose, usage, and various validators provided by default of the validation module.

I. Introduction and usage

In actual project development, we always need to verify the data to ensure data reliability, to enable these verifications to be reused in different places (such as winform, web, and WPF), you need to encapsulate the verification, the validation module of entlib solves this problem. It has a variety of built-in validators, such as string, date, type conversion, and regular expressions, at the same time, we also provide custom verification interfaces to facilitate our expansion based on actual business needs.

In addition, we have added the ASPnet, winform, and WCF validators to the validation module.

 

Ii. Usage

The validation module of the enterprise database provides us with two verification methods:

1. Add features before specific classes, attributes, fields, and methods, such as [stringlengthvalidator (1, 25)]

2. Use the configuration tool provided by the enterprise database to save the verification information to the configuration file through Configuration

Of course, you can also dynamically add verification rules. This is not a common usage method and will not be discussed here.

First, we will introduce the first authentication method:

In the latest entlib5, the validation module was modified, and the inheritance of each validation attribute was also modified. As a result, the original 4.1 attribute could not be used directly before the field.

Error message: stringlengthvalidator is not a valid attributeclass.

See validators in Enterprise Library 5.0

You must reference the above link.System. componentmodel. dataannotationsNamespace, mainly because all validators of the validation module inherit from the namespaceSystem. componentmodel. dataannotationsUnderValidationattributeClass (Msdn Description: serves as the base class for all verification features), So if we need to use the feature Method for entity class or field verification, we must addSystem. componentmodel. dataannotationsReference.

Next, let's take a look at how to use features for verification:

Introduce in the Code:

using Microsoft.Practices.EnterpriseLibrary.Validation;using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

 

Then you can add features before classes, attributes, fields, and methods. The following is a simple string length verification, indicating that the length of the input username must be between 1 and 16:

[Stringlengthvalidator (1, 16, messagetemplate = "the user name must be 1-16 characters in length")] [stringlengthvalidator (1, 16, messagetemplateresourcetype = typeof (libstudy. model. properties. resources), messagetemplateresourcename = "sidmessage")] Public String Sid {Get; set ;}

 

Note the following two points:

1. I have written two types of verification failure error messages, one is to directly write messagetemplate, the advantage of this method is that (This attribute is also set when you use the enterprise database configuration tool for configuration.), The other is to put the error messages in a single resource file. The advantage is that all error messages can be managed in a unified manner, and if the project requires international processing, you can simply add a new resource file. The disadvantage is that it is difficult to write. You need to specify the resource file type and the Resource Name of the corresponding message.

The usage of stringlengthvalidator is described below.

2. When features are used for verification, the features can only be applied to public fields or attributes; otherwise, an error is reported. When there is no automatic Attribute before 3.0, we usually use the following method to write the attribute:

[Stringlengthvalidator (1, 16, messagetemplate = "username length must be 1-16 characters")] private string _ Aid; Public String aid {get {return _ Aid ;} set {_ Aid = value ;}}

 

Unfortunately, this method is wrong because the field specified by the feature is private, and it is not feasible to write the feature to the property aid, because the value is still assigned to _ Aid.

The next step is to introduce how to use the configuration tool of the enterprise database for configuration. However, many people have already written about the configuration method garden. If you want to learn more, you can check it here:

Microsoft Enterprise Library 5.0 series (iii) Validation Application Block (advanced)

Enterprise Library 4.1 validation block quick use of text and text notes

The configuration of each step has been carried out in these two articles. I will not introduce them much.

 

Iii. Introduction to various built-in validators of the validation module

There are already many built-in validators in the validation module, and these validators are also different. I have summarized the classification of these verifications:

1. It can be used as a feature validators, which can be verified directly through features such as class, attribute, and field segment, and can also be verified through configuration. Mainly include:

Containscharactersvalidatorattribute -- whether to include string Verification

Datetimerangevalidatorattribute -- time range Verification

Domainvalidatorattribute -- checks the verification object to determine whether it belongs to a set.

Enumconversionvalidatorattribute -- check whether the string can be converted to an item in the enumeration.

Hasselfvalidationattribute-self-verification, which can only be used for classes and serves selfvalidationattribute

Ignorenullsattribute -- can be empty for verification

Notnullvalidatorattribute -- not empty for verification

Objectcollectionvalidatorattribute -- object set type verification

Objectvalidatorattribute -- object type verification

Propertycomparisonvalidatorattribute -- Property Comparison Verification

Rangevalidatorattribute -- range verification to determine whether an object is in a specified range

Regexvalidatorattribute -- Regular Expression Verification

Relativedatetimevalidatorattribute -- check whether the date belongs to a range relative to the current time or date

Selfvalidationattribute -- self-verification for calling a method

Stringlengthvalidatorattribute -- String Length Verification

Typeconversionvalidatorattribute -- type conversion verification to determine whether it can be converted to a specified type

Validatorcomposition -- Verification bundle that combines different Verifications

2. The independent validators are mainly used for the first authentication service. They can be combined with multiple types of verifications for complex verification, such:

Andcompositevalidator-combination verification, logic and verification. If all the various verifications are passed

Orcompositevalidator-combination verification, logic or verification. If one of the multiple verifications is passed

3. Custom verification. This is an extension provided for extension Verification Based on your business logic.

 

First, we will introduce the first verification method, which can be used as a feature validator:

This type of verification works simply by receiving the information to be verified through the feature class, and then creating the corresponding verification class through the docreatevalidator of the feature class for verification..

  

* Validator features

* The features of such validators are ultimately inherited from the abstract class: basevalidationattribute. The main function of this class is to provide abstract encapsulation of error messages and rules for the subclass.

View Source

Print?

1	public abstract class BaseValidationAttribute : ValidationAttribute

The following fields and methods are used:

1. ruleset: Rule Set. developers can set a rule set for the object to be verified. Different verification methods for a field or attribute can be established under each rule set, for example, in Rule A, the name field must have a length limit of 1-16, and in rule B, whether the field contains the "test" string, in this way, different rules can be verified based on actual needs.

2. messagetemplate, message template, which specifies error messages that fail Verification

3. messagetemplateresourcetype: Type of the resource where the message template is located. specify the type of the resource where the message is stored.

4. messagetemplateresourcename, the name of the resource where the message template is located, and the name of the resource where the message is stored

5. Tag: The verification tag. Obtain or set the feature Verification Result Records represented by the tag.

6. String getmessagetemplate (): method for obtaining the message template. Get the error message through the specified messagetemplateresourcetype and messagetemplateresourcename.

7. bool isvalid (), override the validationattribute. isvalid Method

 

There are two feature classes between the validation feature class and basevalidationattribute:

public abstract class ValidatorAttribute : BaseValidationAttribute, IValidatorDescriptor

 

* This class abstracts the verification logic for the subclass:

1. The createvalidator method calls the validator instance created by docreatevalidator and assigns the tag and message template to the validator instance.

2. The docreatevalidator method is used to create a specific verification instance that implements the validator class for each validator to verify.

1	public abstract class ValueValidatorAttribute : ValidatorAttribute

* This class is used to abstract the feature classes of the validators and overwrite the parent class method:

1. Method isvalid, which overwrites basevalidationattribute. isvalid to determine whether the object value is valid.

2. The formaterrormessage method overrides validationattribute to format the error message.

3. Attribute negated, used to obtain or set the negative logic

In this way, we can clearly understand the specific inheritance relationships of each validator feature class:

Basevalidationattribute-> validatorattribute-> valuevalidatorattribute-> the specific validator feature class is more intuitive. (To be clear, I only put two specific validator feature classes):

As for the specific validator feature class, it is set based on different business logic. I will not explain it here. Anyone who wants to know can or directly read the source code.

 

* Specific verification class

As mentioned above, the specific validator verification is the feature class of the validator (for example:Stringlengthvalidatorattribute) CallValidatorattributeClassDocreatevalidatorMethod to create a specific validator (for example:Stringlengthvalidator.

And specific verification (such:Stringlengthvalidator) The specific structure is also the same as its feature class. The final verification is completed through implementation in layers. First, let's look at the specific inheritance layers:

Validator-> validator <t>-> valuevalidator <t>-> the validator, as shown in the following figure:

View Source

Print?

1	public abstract class Validator

* The abstract class validator is the top-level parent class of all validators., Which defines:

1. Attribute messagetemplate, used to store verification messages

2. Attribute tag, used to store verification results

3. Abstract attribute defamessagetemplate. When messagetemplate is empty, the validator obtains the verification message from defamessmessagetemplate.

4. abstract method dovalidate, which abstracts and defines the Verification Method

5. Use the method validate to call the abstract method dovalidate.

6. Use logvalidationresult to record the verification result.

7. The getmessage method obtains the verification message through the verified object and object value.

View Source

Print?

1	public abstract class Validator<T> : Validator

* The abstract class validator <t> inherits from the abstract class validator. The main function is to extend generic verification for the abstract class validator.

View Source

Print?

1	public abstract class ValueValidator<T> : Validator<T>

* The abstract class valuevalidator <t> inherits from the abstract class validator <t>, which defines:

1. Attribute negated, used to obtain or set the negative logic

2. Method defaultnonnegatedmessagetemplate to obtain the default non-negative verification message template

3. Use defanenegatedmessagetemplate to obtain the default message template for negative verification.

4. rewrite attributesDefaultmessagetemplateAnd definesSealedThe subclass cannot be inherited. The rewritten content is to call the method based on the attribute negated.DefaultnonnegatedmessagetemplateOr MethodDefaultnegatedmessagetemplate

 

* The verification class inherits the abstract class.Valuevalidator <t>RewriteValidator. dovalidateIt verifies based on its own business logic and implements abstract classes.Valuevalidator <t>Definition MethodDefaultnonnegatedmessagetemplateAndDefaultnegatedmessagetemplate

 

So far, I have introduced the basic information, usage, and implementation layers of the validation module of the enterprise database. As this article is a long time ago, so the subsequent use of various validators will be introduced in the next article.

 

PS: The content in this article is my personal understanding. I also referred to the source code of the enterprise database validation module, which may be messy, and there are deviations in some functional purposes, if you find any problems, please correct them. Thank you! Mom

Http://www.cnblogs.com/kyo-yo/archive/2010/07/19/Learning-EntLib-Fifth-Introduction-Validation-module-information-Part1.html