You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let users inject an iValidator object in an alternate constructor that can perform the same operations as the ComponentModel.DataAnnotations.Validator class. This would allow someone to hook in some other validation framework such as FluentValidation. The default constructor could use a static implementation that simply delegates the validation methods to the DataAnnotations.Validator static methods.
In the ValidatableModel class, make these additions / changes:
private IValidator validator;
private static DefaultValidator _defaultValidator = new DefaultValidator();
public void ctor()
{
this.validator = _defaultValidator;
}
public void ctor(IValidator validator)
{
this.validator = validator;
}
public bool Validate()
{
var validationResults = new List<ValidationResult>();
this.validator.TryValidateObject(this, new ValidationContext(this), validationResults, true);
UpdateErrors(validationResults);
return !HasErrors;
}
This puts the onus on those of us that need to use an alternate validation framework to add a class that implements this new interface while still allowing for a default implementation that uses the built-in functionality.
The text was updated successfully, but these errors were encountered:
My design idea is that ValidatableModel provides a basic implementation of the INotifyDataErrorInfo interface for the .NET integrated DataAnnotations.Validator. I prefer to keep it that way just to keep it simple.
If any other validation framework is used then I recommend to use another base class. WAF does not require that you are using the base classes Model or ValidatableModel. Just implement INotifyDataErrorInfo yourself. Alternatively, the validation framework might provide an implementation for this interface.
I understand. It was just nice having everything baked into the base classes, similar to SetProperty and SetPropertyAndValidate. How about allowing the Validate method to be overridden? I was trying to avoid having to implement the INotidyDataErrorInfo and INotifyPropertyChanged in my own base model and then pull in everything that your framework class provides as niceties. But, I suppose that I can always redo it all in a custom implementation that just happens to follow yours. :)
Let users inject an iValidator object in an alternate constructor that can perform the same operations as the ComponentModel.DataAnnotations.Validator class. This would allow someone to hook in some other validation framework such as FluentValidation. The default constructor could use a static implementation that simply delegates the validation methods to the DataAnnotations.Validator static methods.
In the ValidatableModel class, make these additions / changes:
This puts the onus on those of us that need to use an alternate validation framework to add a class that implements this new interface while still allowing for a default implementation that uses the built-in functionality.
The text was updated successfully, but these errors were encountered: