Implement an object verification Library series and verification Library Series

Implement an object verification Library series and verification Library Series
Past Situation Review:

Previous Article 0) describes the Directory and library structure, and briefly describes the code structure of the next database.

This article will explain the overall idea from the interface Section

1) interface Introduction and Overview

For example, I have defined 10 interfaces in total.

These can be divided into two types:

• Creator interfaces defined to support the Fluent syntax format:
  • IFluentRuleBuilder
  • IRuleBuilder
  • IRuleMessageBuilder
  • IValidateRuleBuilder
  • IValidatorBuilder
  • IValidatorSetter
• The rules, results, and definitions of the called interface involved in the verification operation:
  • IRuleSelector
  • IValidateResult
  • IValidateRule
  • IValidator

 

Next, we will first describe the interface design ideas to verify the usage,

Then we will introduce the design idea of rule setting in Fluent format.

(1) design ideas of interfaces used for verification

We first consider the use of user authentication, and we provide users with their own verification rules, not just some fixed verification rules,

In fact, the user just wants to give a data and then get the corresponding result.

Therefore, the general idea of the interface is

public interface IValidator{object Validate(object data);}

In this way, how can users conveniently use the returned values?

The thought is similar to the following:

Public interface IValidateResult {bool IsValid {get;} // The user must first pass the List <ValidateFailure> Failures {get;}/if not, will there be any error information} // the class of the error information, the user is generally concerned about the error in that place, what is wrong, the Error public class ValidateFailure {public string Name {get; set;} public object Value {get; set;} public string Error {get; set ;}}
// So the interface can be changed to public interface IValidator {IValidateResult Validate (object data );}

Think about the parameters. The object certainly does not meet the following requirements:

Public class ValidateContext {public IRuleSelector RuleSelector {get; set;} // in many cases, users may only use some of the verification rules, such as when verifying student information, students and kindergarten students must be different. // Therefore, the user must have a rule selector, public IEnumerable <string> RuleSetList {get; set ;} // most of the time, the rule selectors are the same, but you only need to set some flag for rule selection. a default rule selector is basically enough to use public ValidateOption Option {get; set ;} // sometimes you may need all errors, but sometimes check null first. If it is not null, perform other verification for public object ValidateObject {get; set ;}} public enum ValidateOption {StopOnFirstFailure, continue} public interface IRuleSelector {bool CanExecute (IValidateRule rule, ValidateContext context);} // you can use the final interface public interface IValidator {IValidateResult Validate (ValidateContext context );}

This is the interface method, but how do I save the verification rules? Consider the following:

Public interface IValidateRule {string RuleSet {get; set;} // The identifier of the Rule group. In most cases, the IValidateRule NextRule {get; set;} // a rule is often associated with other rules. For example, if check is null and check length is placed in a class, it is definitely inconvenient for us to define and use string ValueName {get; set;} // has the check data name attribute, so that the user can change this name string Error {get; set;} // has the attribute displaying the Error, in this way, the user can change the value of Func <ValidateContext, bool> Condition {get; set;} // if the rule group does not meet the user requirements, you can only provide such func so that you can filter the Func <ValidateContext, string, string, IValidateResult> ValidateFunc {get; set, to facilitate the expansion of check logic, you do not have to write a ValidateRule class IValidateResult Validate (ValidateContext context) for each new rule check method; // provides the interface for rule calling}

(2) design idea of rule setting method in Fluent format

As we have thought about how to save verification rules, how can we set rules in Fluent mode?

First, let's leave the concept of Fluent and think about how to create rules?

Is that true?

new ValidateRule() {RuleSet = "xx",ValueName = "xx".....}

Let's recall the Fluent method, the chained syntax, and we use it to set verification rules here. It's just the chained use of the Creator mode.

ValidateRule.SetRuleSet("xx").SetValueName("xx")

So we have the rule Creator as follows:

Public interface IValidateRuleBuilder {string RuleSet {get; set ;}string ValueName {get; set ;}string Error {get; set ;}func <ValidateContext, bool> Condition {get; set;} IValidateRuleBuilder NextRuleBuilder {get; set;} Func <ValidateContext, string, string, IValidateResult> ValidateFunc {get; set;} IValidateRule Build (); // similar to IValidateRule, this Build method is missing.} public interface IValidatorBuilder <T> {IFluentRuleBuilder <T, TProperty> RuleFor <TProperty> (Expression <Func <T, TProperty> expression ); void RuleSet (string ruleSet, Action <IValidatorBuilder <T> action); IValidator Build ();}

　　

Fluent is designed to roughly imagine what the final effect is similar, in order to establish the corresponding interface definition

Let's look back at our final results?

ValidatorBuilder.RuleFor(i => i.Age)        .Must(i => i >= 0 && i <= 18)        .OverrideName("student age")        .OverrideError("not student")    .ThenRuleFor(i => i.Name)        .Must(i => !string.IsNullOrWhiteSpace(i))        .OverrideName("student name")        .OverrideError("no name");

Explain our final results:

ValidatorBuilder. ruleFor (I => I. age) // A ValidatorBuilder can create a parent-level verification rule and set the corresponding verification attributes. must (I => I> = 0 & I <= 18) // you Must specify how to verify each rule. overrideName ("student age "). overrideError ("not student") // set the information to be rewritten. thenRuleFor (I => I. name) // a sub-level rule can be created only after the verification method of one rule is set. must (I =>! String. IsNullOrWhiteSpace (I). OverrideName ("student name"). OverrideError ("no name ");

In general, we divide the setting of a rule into several stages, which are irreversible and strictly ordered.

• Initially, a parent verification rule is created, and corresponding verification attributes are set.
• Set how to verify
• Enter descriptions or create Sub-Level Rules

So our interface will be as follows:

Public interface IValidatorBuilder <T> {IFluentRuleBuilder <T, TProperty> RuleFor <TProperty> (Expression <Func <T, TProperty> expression); void RuleSet (string ruleSet, action <IValidatorBuilder <T> action); IValidator Build () ;}// corresponds to the initial creation of parent-level verification rules, the public interface IFluentRuleBuilder <T, TProperty >{}// sets the authentication method. In this phase, public interface IRuleMessageBuilder <T, TValue >{ifluentrulebuilder <T, TProperty> ThenRuleFor <TProperty> (Expression <Func <T, TProperty> expression );} // enter some description information or create Sub-Level Rules. At this stage, public interface IRuleBuilder <T, TValue>: IValidateRuleBuilder, IRuleMessageBuilder <T, TValue>, IFluentRuleBuilder <T, TValue> {Func <object, TValue> ValueGetter {get;} Expression <Func <T, TValue> ValueExpression {get;} void SetValueGetter (Expression <Func <T, TValue> expression);} // sums up the final definitions of the three phases

All of the above are the interface design ideas.

The following describes how to implement

 

 

NEXT: 2) validator implementation