Validation

[nickrandolph]

Two scenarios for validation:

• Pre-validation before data is fetched eg user enters information in a form, validation would be invoked prior to calling a service method to ensure data meets validation rules
• Real-time validation eg as user enters data into a form, validation would be invoked to provide real-time feedback to the user.

There are a number of existing validation related projects that should be considered:

• Community MVVM toolkit - validation attributes
• Fluent validation - a fluent api for defining validation rules
• MADE validation (https://github.com/MADE-Apps/MADE-Uno)

[nickrandolph]

MADE

Defines an IValidator
Basic idea is that viewmodel defines a collection of validators; the XAML uses the InputValidator control to add validation errors to the UI

FluentValidation

Defines IValidator
Basic idea is that you pass the object you want to validate into the Validate method

MVVM Toolkit

Defines ObservableValidator
Leverages INotifyDataError interface along with ValidationAttributes
Basic idea is that the object you want to validate inherits from ObservableValidator

[nickrandolph]

Proposed design:

• Define IValidator interface that exposes ValidateAsync method (similar to those defined by FluentValidation library except ValidationResult would come from System.ComponentModel.DataAnnotations and it supports ValidationContext to allow finer control over which properties are validated)

public interface IValidator<in T> : IValidator {
    ValueTask<IEnumerable<ValidationResult>> ValidateAsync(T instance, ValidationContext? context=null, CancellationToken cancellation = new CancellationToken());
}

• IValidator implementations would be registered in DI container and could then be retrieved in any viewmodel and/or service

Extensions.Validation
Defines IValidator and ValidationResult
Defines SystemValidator:IValidator with the implementation based on calling GetErrors method (defined in the INotifyDataErrorInfo interface) or the Validate method on the IValidatableObject interface
For platforms that support it, this can use the Validator internally to do the heavy lifting
Call HostBuilder.UseValidation() to register validator

Extensions.Validation.Fluent
Defines FluentValidator:IValidator which takes FluentValidation.IValidator as a constructor argument. FluentValidator is a proxy/adapter for calling the underlying fluent validator.
Call HostBuilder.UseFluentValidation() to register to use fluent validation. Also need to register Fluent validators (ie https://docs.fluentvalidation.net/en/latest/di.html).

Extensions.Validation.CommunityToolkit
Defines CommunityToolkitValidator:IValidator which has built in support for validating objects that inherit from ObservableValidator
Call HostBuilder.UseCommunityToolkitValidation() to register validator

[dr1rrb]

Open question:

Should we have just a non generic IValidator with a generic ValidateAsync<T>(T instance...) ... or even non generic ValidateAsync(object instance ...). Then the IValidator implementation will basically be a registry which resolve the validator for the type.

Pros:

• We are able to decide at runtime what to do if there is no validator for the given type (throw or empty result)
• We will be able to properly support inheritance (while resolving IValidator<T> on the DI might not return the IValidator<BaseOfT>)
• We can resolve and use the IValidator from the UI without using reflection (MakeGeneric)

Cons:

• It will defer to the validation time the possible exception if there is no validator for T

[francoistanguay]

Can both Community and Fluent work in non-generic ways?