ASP. net mvc Model verification (4), mvcmodel

ASP. net mvc Model verification (4), mvcmodel
ASP. net mvc ModelVerify(Thu)Preface

This topic describes two types of custom implementation: ModelValidatorProvider and ModelValidator. The former is the Model verification provider, and the ModelValidator type is the Model verification execution type, in the following example, the Model verification provider is used in combination with the Model verification execution type to perform Model verification. The Model binder mentioned in the previous section is inherited from the defamodelmodelbinder type, use the ModelValidator type in the custom Model binder.

 

Model Verify

• ModelSimple Example
• ModelValidatorUse the generation process
• Custom defamodelmodelbinderVerify
• Custom ModelValidatorProviderAnd ModelValidator
• ValidationAttributeFeature usage
• Customize ValidationAttributeImplementation of feature classes

 

Custom ModelValidatorProvider and ModelValidator

ModelValidator

Take a deep breath and enter the topic.

Before defining the custom ModelValidator type, let's take a look at the definition of the ModelValidator type. Code 1-1.

Code 1-1

Public abstract class ModelValidator {protected ModelValidator (ModelMetadata metadata, ControllerContext controllerContext); protected internal ControllerContext {get;} public virtual bool IsRequired {get;} // abstract: // obtain the metadata of the model verification program. //// Returned result: // metadata of the model verification program. Protected internal ModelMetadata Metadata {get;} public virtual IEnumerable <ModelClientValidationRule> encrypt (); public static ModelValidator GetModelValidator (ModelMetadata metadata, ControllerContext context); // Abstract: // implement the current verification object in the derived class. //// Parameter: // container. //// Return result: // list of verification results. Public abstract IEnumerable <ModelValidationResult> Validate (object container );}

In code 1-1, we can see that the structure of the ModelValidator type can be rewritten, so that we can customize some required data, but this is not done in the following example, the purpose is to make a simple demonstration. Then let's take a look at the Metadata attribute. This attribute is very important. It indicates that the information of the Model or Model attribute to be verified is encapsulated, the final thing we should look at is the Validate () abstract method. We must implement this method for custom types. There is a ModelValidationResult type in its return type. Let's take a look at the ModelValidationResult type, code 1-2.

Code 1-2

Public class ModelValidationResult {public ModelValidationResult (); // Summary: // get or set the member name. //// Return result: // member name. Public string MemberName {get; set;} // Abstract: // obtain or set the verification result message. //// Return result: // verification result message. Public string Message {get; set ;}}

 

As you can see, there is nothing to say about code 1-2. After reading this article, you will naturally understand it.

ASP. net mvc Model validation (3) and ASP. net mvc Model verification (1). Some of my friends may have read it, if you have not read this article, you are advised to take a quick look at the sample parts of Article 1 and Article 3 (the basic part of this example depends on the basic part of the previous article. The reason for the length is not described again here ), here I want to say that Model verification is also classified, that is, the Model-level verification and Model attribute-level verification mentioned in the previous article. In the following example, I split the verification process in the previous article into three parts (which can be written together for ease of understanding ).

I define the first part as Model attribute-level verification. Let's take a look at the sample code 1-3.

Code 1-3

Public class Metadata: ModelValidator {public Metadata (ModelMetadata modelMetadata, ControllerContext controllContext): base (modelMetadata, controllContext) {} public override IEnumerable <ModelValidationResult> Validate (object container) {switch (Metadata. propertyName) {case "ID": if (string. isNullOrEmpty (string) container) | (string) container =" ") {Return new ModelValidationResult [] {new ModelValidationResult () {MemberName =" ID ", Message =" enter an ID. The ID cannot be blank! "}};} Break; case" UserID ": if (string. isNullOrEmpty (string) container) | (string) container = "") {return new ModelValidationResult [] {new ModelValidationResult () {MemberName = "UserID ", message = "enter a user account. The user account cannot be blank! "}};} Break; case" Password1 ": if (string. isNullOrEmpty (string) container) | (string) container = "") {ControllerContext. controller. tempData. add ("Password1", false); return new ModelValidationResult [] {new ModelValidationResult () {MemberName = "Password1", Message = "Enter the logon password. The logon password cannot be blank! "}};} Break; case" Password2 ": if (string. isNullOrEmpty (string) container) | (string) container = "") {ControllerContext. controller. tempData. add ("Password2", false); return new ModelValidationResult [] {new ModelValidationResult () {MemberName = "Pssword2", Message = "enter the password again. The password cannot be blank! "}};} Break; case" Name ": return Enumerable. Empty <ModelValidationResult> () ;}return Enumerable. Empty <ModelValidationResult> ();}}

 

First, we define a MyCustomModelPropertyValidator type in code 1-3, and define the constructor. This is very important (you can see the Model verification provider Section). In Validate () some attributes are verified and returned according to the return type restricted by the method. For the implementation part of the code, after reading the previous article, I learned that the Model property verification will be performed when the default Model binder binds the Model property, and the MyCustomModelPropertyValidator type verification method will be called cyclically in the traversal process, if you have any questions, go to the previous article.

Let's take a look at the second part. The second part mainly verifies whether the two passwords are the same. Let's look at the sample code 1-4.

Code 1-4

Public class metadata: ModelValidator {public metadata (ModelMetadata modelMetadata, ControllerContext controllerContext): base (modelMetadata, controllerContext) {}public override IEnumerable <ModelValidationResult> Validate (object container) {Models. registrationInformation regInfo = Metadata. model as Models. registrationInformation; if (regInfo! = Null) {if (! ControllerContext. Controller. TempData. ContainsKey ("Password1 ")&&! ControllerContext. Controller. TempData. ContainsKey ("Password2") {if (regInfo. Password1! = RegInfo. Password2) {return new ModelValidationResult [] {new ModelValidationResult () {MemberName = "Password2", Message = "enter a new password, which is different from the previous password! "}};}} Return Enumerable. Empty <ModelValidationResult> ();}}

 

In code 1-4, a careful friend found that there is a big difference with the implementation method of code 1-3, Because I defined this MyCustomModelPassWordValidator type as Model-level verification, the MyCustomModelPassWordValidator type is called in the OnModelUpdated () method of the default Model binder after the Model attribute is verified and bound, therefore, you can directly obtain the value of the Model through the Model attribute of Metadata for verification. controller. tempData. the meaning of the ContainsKey ("Password1") code is to determine whether the Password1 attribute of the Model has passed the attribute-level verification, because messages cannot be transmitted between each Model validator, only ControllerContext points to a reference. It carries data information. It has been defined in code 1-3. (If you do not understand the second part, you can refer to the previous article and this article)

Now let's look at the third part, which is the same as the second part. The sample code is 1-5.

Code 1-5

Public class metadata: ModelValidator {public metadata (ModelMetadata modelMetadata, ControllerContext controllerConttext): base (modelMetadata, controllerConttext) {} public override IEnumerable <ModelValidationResult> Validate (object container) {Models. registrationInformation regInfo = Metadata. model as Models. registrationInformation; if (regInfo! = Null) {if (string. compare (regInfo. name, "jinyuan", true) = 0) {return new ModelValidationResult [] {new ModelValidationResult () {MemberName = "", Message = "the Name you entered is invalid, change now or check the water meter "}}}} return Enumerable. empty <ModelValidationResult> ();}}

 

The function of code 1-5 is to verify the Name attribute of the Model during Model-level verification.

 

ModelValidatorProvider

The previous section defines three parts. The first part is Model attribute-level verification, and the second part is Model-level verification. However, when the default Model binder (defamodelmodelbinder type) is executed, it does not matter, it is only responsible for from ModelValidatorProviders. in Providers, we obtain the custom Model validators provider (ModelValidatorProvider type instance), and then the Model validators provider provides it with the Model validators, at this time, our custom Model validators provider needs to determine where we are called and return the corresponding Model validators. Let's look at the sample code 1-6.

Code 1-6

namespace MvcApplication.ModelValidators{    public class MyCustomModelValidatorProvider:ModelValidatorProvider    {        public override IEnumerable<ModelValidator> GetValidators(ModelMetadata metadata, ControllerContext context)        {            if (metadata.ContainerType == typeof(Models.RegistrationInformation))            {                return new ModelValidator[]                {                    new MyCustomModelPropertyValidator(metadata,context)                };            }            else if (metadata.ModelType == typeof(Models.RegistrationInformation))            {                return new ModelValidator[]                 {                    new MyCustomModelPassWordValidator(metadata,context),                    new MyCustomModelNameValidator(metadata,context)                };            }            return Enumerable.Empty<ModelValidator>();        }    }}

 

In code 1-6, we define a custom Model validators provider MyCustomModelValidatorProvider type. In MyCustomModelValidatorProvider type, it is based on GetValidators () the metadata parameter of the method contains information to determine where you are called by the default Model binder (defamodelmodelbinder type. (For the Model metadata section, you can refer to the Model metadata series I have previously shared with you)

Almost all of them have been completed here, and it cannot be used when registered to the system. Some friends will scold me and cannot use it for a long time. You are not in a hurry. Let me explain it, the reason is that our custom Model validators and Model validators are subject to the call constraints of the default Model binder (DefaultModelBinder type) of the MVC framework, it must be written in and out according to the internal definition of the method. Here we do not need to worry about it, and then define a custom DefaultModelBinder type Model binder. Let's look at the example code 1-7.

Code 1-7

    public class MyCustomModelValidatorDefaultModelBinder : DefaultModelBinder    {        protected override void SetProperty(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor propertyDescriptor, object value)        {            base.SetProperty(controllerContext, bindingContext, propertyDescriptor, value);            foreach (ModelValidator modelValidator in ModelValidatorProviders.Providers.GetValidators(bindingContext.PropertyMetadata[propertyDescriptor.Name], controllerContext))            {                IEnumerable<ModelValidationResult> modelValidationResults = modelValidator.Validate(value);                foreach (ModelValidationResult modelValidationResult in modelValidationResults)                {                    bindingContext.ModelState.AddModelError(modelValidationResult.MemberName, modelValidationResult.Message);                }            }        }        protected override void OnModelUpdated(ControllerContext controllerContext, ModelBindingContext bindingContext)        {            //base.OnModelUpdated(controllerContext, bindingContext);            foreach (ModelValidator modelValidator in ModelValidatorProviders.Providers.GetValidators(bindingContext.ModelMetadata, controllerContext))            {                IEnumerable<ModelValidationResult> modelValidationResults = modelValidator.Validate(null);                foreach (ModelValidationResult modelValidationResult in modelValidationResults)                {                    bindingContext.ModelState.AddModelError(modelValidationResult.MemberName, modelValidationResult.Message);                }            }        }    }

 

With the Model binder in code 1-7, we can match the Model validators and providers we defined earlier.

I want to register the MyCustomModelValidatorProvider type and mycustommodelvalidatordefamodelbinder type to the system, and add Part 1-8 of the sample code to the Application_Start () method of the Global. asax file.

Code 1-8

ModelBinders.Binders.Add(typeof(Models.RegistrationInformation), new Binders.MyCustomModelValidatorDefaultModelBinder());ModelValidatorProviders.Providers.Insert(0, new ModelValidators.MyCustomModelValidatorProvider());

 

See 1. Figure 1 shows the initial display page, and Figure 2 shows the verification after you click submit in Figure 1.

Figure 1

Figure 2

 

Author: Jin Yuan

Source: http://www.cnblogs.com/jin-yuan/

The copyright of this article is shared by the author and the blog Park. You are welcome to reprint this article. However, you must keep this statement without the author's consent and go to the Article Page.

Model Verification of aspnet mvc

In this case, do not use feature verification. Use the IValidatableObject interface.
The model implements the IValidatableObject interface, and then implements it in it. For example, I want to get a date comparison.
Public IEnumerable <ValidationResult> Validate (ValidationContext validationContext) {if (this. _ AnnouncementDateEnd <this. _ expiration) {yield return new ValidationResult ("the end date must be later than the start date! ");}}

Confirm the password verification in ASPNET MVC40. Let's take a look at the situation.

Reference System. Web. Mvc