Validation

Appccelerate provides classes for implementing validation logic out-of-the-box. All validation relevant types can be found in the namespace Appccelerate.EvaluationEngine.Validation.

Simple Validation

Assume that the following class Data has to be validated before it is sent to a service:

For the data to be valid, two rules have to be verified:

The NameSetRule verifies that the name is set and the DescriptionSetRule verifies that the description is set. If the detect that something is wrong, they set the result to invalid (Valid = false) and add a violation reason. These violations are aggregated so that all violations can be used for example in an error message.

In order to ask the evaluation engine whether data is valid we need a question:

Now let's tell the evaluation engine that it should use these two rules when validating data:

This tells the evaluation engine that the question IsDataValid has to be solved by using the validation aggregator and both rules we've defined above.

Someone interested in whether some data is valid can then question the evaluation engine:

The code can then react to whether validationResult.Valid is true or false. In case of invalid data, the property validationResult.Violations contains a list of all found violations.

Extend Validation for your Needs

The simple validation shown above returns only whether the result is valid and a list of violations containing an error reason. In real world applications there is the need to specify additional data in the validation result and in the violation. For example identifiers identifying an item with an error, error codes, navigation instructions and so on.

The evaluation engine allows you to extend the base classes shown in the simple validation example.

Extend Validation Violations

First, derive an interface from IValidationViolation and add the data you want to be included in the result of the validation:

Extend Validation Result

Second, we need to define that our violations should be used in the validation result. To do so, we our own validation result interface and define that it contains our violations:

Define the Validation Result Factory

You can still use the built in validation aggregator. But you have to tell the aggregator how to create validation results and violations. Therefore, we define a factory and pass it to the aggregator in the solution definition syntax:

Write Rules

Now we can change our rules to set our data on the violation:

Note that a factory is used to create the validation result and the violation. These calls will call the creation method on the factory we declared above.

Optionally write your own Aggregator

If you want to return custom data on the validation result, you need to implement your own aggregator (see aggregators) because you have to specify how the different result of the individual expressions/rules should be combined into a single result. The default validation aggregator simply collects all violations and if at least one validation result of an expression is invalid, the whole validation result is invalid.