FluentValidation
FluentValidation copied to clipboard
Enable interception of model type used to fetch validators (for proxy type scenarios)
EditContextFluentValidationExtensions.GetValidatorForModel uses model.GetType() to determine what validator to fetch from the service provider. The majority of my view models are proxied at runtime and so model.GetType() will return the runtime-generated proxy type, not the underlying compile-time type being proxied. The result is that validators will sometimes not be found.
My proposal is to add a new parameter to EditContextFluentValidationExtensions.AddFluentValidation (in a non-breaking fashion).
public delegate Type InterceptEditContextModelTypeDelegate(object model);
public static EditContext AddFluentValidation(this EditContext editContext, IServiceProvider serviceProvider, bool disableAssemblyScanning, IValidator validator, FluentValidationValidator fluentValidationValidator)
=> editContext.AddFluentValidation(serviceProvider, disableAssemblyScanning, validator, fluentValidationValidator, model => model.GetType());
public static EditContext AddFluentValidation(this EditContext editContext, IServiceProvider serviceProvider, bool disableAssemblyScanning, IValidator validator, FluentValidationValidator fluentValidationValidator, InterceptEditContextModelTypeDelegate modelTypeInterceptor)
{
...
}
private static IValidator GetValidatorForModel(IServiceProvider serviceProvider, object model, bool disableAssemblyScanning, InterceptEditContextModelTypeDelegate modelTypeInterceptor)
{
var modelType = modelTypeInterceptor.Invoke(model);
...
}
I can submit a PR for this later.
Hi Ryan, thanks for raising this. It seems like a good suggestion. I've just had a quick look at your PR as well and it looks good I think we can get this feature in.
Awesome! I can add some documentation to the README. Would you prefer that be done as part of the PR or after a new version of the package is released?
That would be fantastic! Could you add it as part of the existing PR.
Documentation added to the existing PR
Actually, this scenario would be very well covered by #88 - ValidatorFactory callback which returns directly IValidator instance.
Advantage of ValidatorFactory is that it cover much more scenarios. For example you might used different validators for the same model type, you can use your own validator discovery logic, etc...
In fact, existing AssemblyScanning and ServiceProvider activation could be refactored as a ValidatorFactory callbacks.