In some application solutions, we need to check and verify data, and filter out illegal or unreasonable data. Therefore, it is necessary to integrate a validator in LeoVisitor so that it can be verified directly during the setup phase.
Since the requirement of the validator is not a general requirement, adding validation to the core library DictBase will pay extra. Therefore, it is an ideal choice to add an optional verification context in LeoVisitor to implement data verification.
I will record this part of the notes here in the form of a memo.
Set verification policy at creation time
To set the validation rules when creating LeoVisitor, we can pass in a strategy object (which implements the ILeoValidationStrategy interface) to the LeoVisitorFactory factory method:
var visitor = LeoVisitorFactory.Create(Type, Instance, ValidationStrategy);
// or
var visitor = LeoVisitorFactory.Create<T>(Instance, ValidationStrategy);
// or
var visitor = LeoVisitorFactory.Create<T, TStrategy>(Instance);
For LeoVisitor created with an initial data set (IDictionary implementation), the verification strategy can also be passed in when creating:
var d = new Dictionary<string, object>();
var visitor = LeoVisitorFactory.Create(Type, ValidationStrategy, d);
// or
var visitor = LeoVisitorFactory.Create<T>(ValidationStrategy, d);
// or
var visitor = LeoVisitorFactory.Create<T, TStrategy>(d);
Set or override the verification strategy in LeoVisitor
An API should be provided so that verification rules can be set or updated on LeoVisitor:
- Set verification rules for the entire Visitor, or overwrite existing verification rules as a whole.
var validationEntry = visitor.Validation;
validationEntry.SetStrategy(StrategyInstance, OverwriteOrUpdateFlag); // OverwriteOrUpdateFlag default is overwrite
// or
validationEntry.SetStrategy<TStrategy>(OverwriteOrUpdateFlag);
- Set or override verification rules for individual fields or properties.
var validationEntry = visitor.Validation;
validationEntry.Member(Name, ValueRule);
// or
validationEntry.Member<TVal>(Expression<Func<T, TVal>> expression, ValueRule); //for IValitionEntry<T>
validationEntry.Member<T, TVal>(Expression<Func<T, TVal>> expression, ValueRule); //for IValitionEntry
// or
validationEntry.Member<TVal, TRule>(Expression<Func<T, TVal>> expression); //for IValitionEntry<T>
validationEntry.Member<T, TVal,TRule>(Expression<Func<T, TVal>> expression); //for IValitionEntry
// or (Not recommended)
validationEntry.Member<TVal>(Expression<Func<T, TVal>> expression).Required(); //fluent api for IValitionEntry<T>
validationEntry.Member<T, TVal>(Expression<Func<T, TVal>> expression).Required(); //fluent api for IValitionEntry
- When the entire verification rule is overridden, whether to clear all the rules or only cover the set of rules for a given field or property.
When to verify data
When LeoVisitor is created and a strategy is given, the value in LeoVisitor should not be checked immediately. I think it should be checked when the results are obtained to avoid time-consuming creation.
We may need to provide a parameter to indicate whether the policy is strict or non-strict. When using strict rules, each of our SetValue operations will check the value; when using non-strict rules, we will perform a check only when we get the verification result.
This applies to both instance setters and value setters.
Support for other verification components
Do we need to consider supporting other verification components? For example, tell users how to extend LeoVisitor's verification capabilities to integrate FluentValidation?
In addition, do we need to support the DataAnnotation that comes with .NET?
How to extend the support for user-designed verification components? This requires us to discuss together.
Throw an exception, or silently collect errors?
For LeoVisitor, I think the silent mode is more suitable. Throwing an exception directly loses the original intention of verifying data. We should be able to obtain a set of error messages so that we can return and inform the user.
Of course, for similar low-code platforms, they should be able to verify data at the front end. Then the LeoVisitor verifier at the back end can be regarded as a two-stage verification. So throwing exceptions directly is not in practice. Of course, we can provide a pair of APIs, similar to Verify and VerifyAndThrow.
At last
I think LeoVisitor's validator should not be designed to be too complicated and too many functions. Even, whether we should use Fluent APIs is a matter of thinking. Fluent APIs can make the code difficult to read in this case.
In some application solutions, we need to check and verify data, and filter out illegal or unreasonable data. Therefore, it is necessary to integrate a validator in LeoVisitor so that it can be verified directly during the setup phase.
Since the requirement of the validator is not a general requirement, adding validation to the core library
DictBasewill pay extra. Therefore, it is an ideal choice to add an optional verification context in LeoVisitor to implement data verification.I will record this part of the notes here in the form of a memo.
Set verification policy at creation time
To set the validation rules when creating LeoVisitor, we can pass in a strategy object (which implements the
ILeoValidationStrategyinterface) to theLeoVisitorFactoryfactory method:For LeoVisitor created with an initial data set (IDictionary implementation), the verification strategy can also be passed in when creating:
Set or override the verification strategy in LeoVisitor
An API should be provided so that verification rules can be set or updated on LeoVisitor:
When to verify data
When LeoVisitor is created and a strategy is given, the value in LeoVisitor should not be checked immediately. I think it should be checked when the results are obtained to avoid time-consuming creation.
We may need to provide a parameter to indicate whether the policy is strict or non-strict. When using strict rules, each of our SetValue operations will check the value; when using non-strict rules, we will perform a check only when we get the verification result.
This applies to both instance setters and value setters.
Support for other verification components
Do we need to consider supporting other verification components? For example, tell users how to extend LeoVisitor's verification capabilities to integrate FluentValidation?
In addition, do we need to support the DataAnnotation that comes with .NET?
How to extend the support for user-designed verification components? This requires us to discuss together.
Throw an exception, or silently collect errors?
For LeoVisitor, I think the silent mode is more suitable. Throwing an exception directly loses the original intention of verifying data. We should be able to obtain a set of error messages so that we can return and inform the user.
Of course, for similar low-code platforms, they should be able to verify data at the front end. Then the LeoVisitor verifier at the back end can be regarded as a two-stage verification. So throwing exceptions directly is not in practice. Of course, we can provide a pair of APIs, similar to
VerifyandVerifyAndThrow.At last
I think LeoVisitor's validator should not be designed to be too complicated and too many functions. Even, whether we should use Fluent APIs is a matter of thinking. Fluent APIs can make the code difficult to read in this case.