Class DecimalInRange
A validation rule which passes if the validated System.Decimal or System.Nullable<T> decimal is within an inclusive Min & Max range.
Inheritance
Implements
Inherited Members
Namespace: CSF.Validation.Rules
Assembly: CSF.Validation.StandardRules.dll
Syntax
public class DecimalInRange : IRuleWithMessage<decimal>, IRule<decimal>, IGetsFailureMessage<decimal>, IRuleWithMessage<decimal?>, IRule<decimal?>, IGetsFailureMessage<decimal?>
Remarks
Either of Min or Max may be null. If either is null then either the minimum or maximum of the range will not be used (which means that this becomes simply a "greater-then" or "less-than" validation rule). If both ends of the range are null then this validation rule will always pass.
This validation rule may additionally be used with System.Nullable<T> numbers, in which case this rule will pass if the validated value is null. Combine this rule with a NotNull rule if nulls are not permitted.
The logic of this rule does not verify that the minimum is not greater-than the maximum. Thus it is possible to set up scenarios where this rule will always return a failure result for any number, as the pass criteria cannot be satisfied.
This rule supports both non-nullable and nullable instances of System.Decimal.
This rule will always return a synchronous result.
Properties
| Improve this Doc View SourceMax
Gets or sets the (inclusive) maximum for the validated value.
Declaration
public decimal? Max { get; set; }
Property Value
Type | Description |
---|---|
System.Nullable<System.Decimal> |
Min
Gets or sets the (inclusive) minimum for the validated value.
Declaration
public decimal? Min { get; set; }
Property Value
Type | Description |
---|---|
System.Nullable<System.Decimal> |
Methods
| Improve this Doc View SourceGetFailureMessageAsync(Nullable<Decimal>, ValidationRuleResult, CancellationToken)
Gets the validation failure message for the specified result.
Declaration
public ValueTask<string> GetFailureMessageAsync(decimal? value, ValidationRuleResult result, CancellationToken token = default(CancellationToken))
Parameters
Type | Name | Description |
---|---|---|
System.Nullable<System.Decimal> | value | |
ValidationRuleResult | result | A validation result, typically indicating failure. |
System.Threading.CancellationToken | token | An optional cancellation token. |
Returns
Type | Description |
---|---|
System.Threading.Tasks.ValueTask<System.String> | A human-readable message. |
GetResultAsync(Decimal, RuleContext, CancellationToken)
Performs the validation logic asynchronously and returns a task of RuleResult.
Declaration
public ValueTask<RuleResult> GetResultAsync(decimal validated, RuleContext context, CancellationToken token = default(CancellationToken))
Parameters
Type | Name | Description |
---|---|---|
System.Decimal | validated | |
RuleContext | context | Contextual information about the validation |
System.Threading.CancellationToken | token | An object which may be used to cancel the process |
Returns
Type | Description |
---|---|
System.Threading.Tasks.ValueTask<RuleResult> | A task which provides a result object, indicating the result of validation |
Remarks
This method receives the value to be validated as well as an object which represents the context in which this rule is running. It should return a task of RuleResult.
In order to create the result object, particularly if your rule logic will run synchronously,
consider using the CommonResults class via using static CSF.Validation.Rules.CommonResults;
in your
rule logic.
The common results class has helper methods such as PassAsync(IDictionary<String, Object>)
and FailAsync(IDictionary<String, Object>)
which include optimisations for flyweight task instances that avoid allocating additional resources
needlessly.
It is acceptable to throw an uncaught exception from this method, as the validation framework will catch it and automatically convert it into an error result. Generally, developers do not need to manually return a result of outcome Errored manually. This would be appropriate only in an unusual scenario that is considered an error, but which does not involve the throwing of an exception. Error results are generally harder for the consumer to deal with than failure results.
The context
parameter may be used, amongst other things, to access 'ancestor'
values.
However, if this rule only needs access to an immediate parent value then consider using
IRule<TValue, TParent> instead.
Exceptions
Type | Condition |
---|---|
System.Exception | This method may raise any exception type |
GetResultAsync(Nullable<Decimal>, RuleContext, CancellationToken)
Performs the validation logic asynchronously and returns a task of RuleResult.
Declaration
public ValueTask<RuleResult> GetResultAsync(decimal? validated, RuleContext context, CancellationToken token = default(CancellationToken))
Parameters
Type | Name | Description |
---|---|---|
System.Nullable<System.Decimal> | validated | |
RuleContext | context | Contextual information about the validation |
System.Threading.CancellationToken | token | An object which may be used to cancel the process |
Returns
Type | Description |
---|---|
System.Threading.Tasks.ValueTask<RuleResult> | A task which provides a result object, indicating the result of validation |
Remarks
This method receives the value to be validated as well as an object which represents the context in which this rule is running. It should return a task of RuleResult.
In order to create the result object, particularly if your rule logic will run synchronously,
consider using the CommonResults class via using static CSF.Validation.Rules.CommonResults;
in your
rule logic.
The common results class has helper methods such as PassAsync(IDictionary<String, Object>)
and FailAsync(IDictionary<String, Object>)
which include optimisations for flyweight task instances that avoid allocating additional resources
needlessly.
It is acceptable to throw an uncaught exception from this method, as the validation framework will catch it and automatically convert it into an error result. Generally, developers do not need to manually return a result of outcome Errored manually. This would be appropriate only in an unusual scenario that is considered an error, but which does not involve the throwing of an exception. Error results are generally harder for the consumer to deal with than failure results.
The context
parameter may be used, amongst other things, to access 'ancestor'
values.
However, if this rule only needs access to an immediate parent value then consider using
IRule<TValue, TParent> instead.
Exceptions
Type | Condition |
---|---|
System.Exception | This method may raise any exception type |
Explicit Interface Implementations
| Improve this Doc View SourceIGetsFailureMessage<Decimal>.GetFailureMessageAsync(Decimal, ValidationRuleResult, CancellationToken)
Declaration
ValueTask<string> IGetsFailureMessage<decimal>.GetFailureMessageAsync(decimal value, ValidationRuleResult result, CancellationToken token)
Parameters
Type | Name | Description |
---|---|---|
System.Decimal | value | |
ValidationRuleResult | result | |
System.Threading.CancellationToken | token |
Returns
Type | Description |
---|---|
System.Threading.Tasks.ValueTask<System.String> |