基于FluentValidation的API请求模型自动验证方案优化咨询

Nice work getting the core auto-validation flow working! Based on my experience with FluentValidation and the .NET ecosystem, here are some polished, production-ready optimizations you can apply to make this implementation cleaner, faster, and more maintainable:

Instead of manual assembly scanning or instance management, leverage your app's DI container to handle validator lookup. This keeps code decoupled and aligns with .NET best practices:

public async Task ValidateModelIfSupportedAsync<T>(T model, IServiceProvider serviceProvider)
{
    // Check if a validator exists for the model type via DI
    var validator = serviceProvider.GetService<IValidator<T>>();
    
    if (validator is not null)
    {
        var validationResult = await validator.ValidateAsync(model);
        
        if (!validationResult.IsValid)
        {
            // Use FluentValidation's built-in exception for consistent error handling
            throw new ValidationException(validationResult.Errors);
        }
    }
}

This approach lets your DI container manage validator registration (via services.AddValidatorsFromAssemblyContaining<YourValidator>() in ASP.NET Core) and avoids manual type-scanning overhead.

For web apps, an async action filter can automate validation across all endpoints without manual calls in controllers. This keeps business logic free of validation boilerplate:

public class AutoValidateModelFilter : IAsyncActionFilter
{
    private readonly IServiceProvider _serviceProvider;
    private static readonly ConcurrentDictionary<Type, bool> _validatorCache = new();

    public AutoValidateModelFilter(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        foreach (var (_, model) in context.ActionArguments)
        {
            if (model is null) continue;
            
            var modelType = model.GetType();
            // Cache validator existence to avoid repeated reflection/DI lookups
            var hasValidator = _validatorCache.GetOrAdd(modelType, type => 
            {
                var validatorInterface = typeof(IValidator<>).MakeGenericType(type);
                return _serviceProvider.GetService(validatorInterface) is not null;
            });

            if (hasValidator)
            {
                var validator = _serviceProvider.GetService(typeof(IValidator<>).MakeGenericType(modelType));
                var validateMethod = validator.GetType().GetMethod(nameof(IValidator<object>.ValidateAsync), new[] { modelType });
                
                var validationResult = await (Task<ValidationResult>)validateMethod.Invoke(validator, new[] { model });
                
                if (!validationResult.IsValid)
                {
                    // Map errors to ModelState for consistent API responses
                    foreach (var error in validationResult.Errors)
                    {
                        context.ModelState.AddModelError(error.PropertyName, error.ErrorMessage);
                    }
                    context.Result = new BadRequestObjectResult(context.ModelState);
                    return;
                }
            }
        }

        await next();
    }
}

Register it in Program.cs to enable across all controllers:

builder.Services.AddControllers(options =>
{
    options.Filters.Add<AutoValidateModelFilter>();
});

Wrap validation logic in extension methods to make calls more readable and self-documenting—perfect for non-web scenarios like background services or console apps:

public static class ValidationExtensions
{
    public static async Task ValidateIfValidatorExistsAsync<T>(this T model, IServiceProvider serviceProvider)
    {
        ArgumentNullException.ThrowIfNull(model);
        ArgumentNullException.ThrowIfNull(serviceProvider);

        var validator = serviceProvider.GetService<IValidator<T>>();
        // Use FluentValidation's shortcut to validate and throw if invalid
        await validator?.ValidateAndThrowAsync(model)!;
    }
}

Now you can call it anywhere with:

await myModel.ValidateIfValidatorExistsAsync(serviceProvider);

As shown in the action filter example, caching whether a model type has a validator avoids repeated reflection and DI lookups. For high-throughput apps, this small optimization reduces overhead. Use ConcurrentDictionary to ensure thread-safe caching.

If you need to pass context-specific data (like current user ID or request metadata) to validators, extend the logic to accept ValidationContext<T>:

public static async Task ValidateIfValidatorExistsAsync<T>(this T model, ValidationContext<T> context, IServiceProvider serviceProvider)
{
    var validator = serviceProvider.GetService<IValidator<T>>();
    if (validator is not null)
    {
        var result = await validator.ValidateAsync(context);
        result.ThrowIfInvalid();
    }
}

You can inject context data like this:

var validationContext = new ValidationContext<MyModel>(model)
{
    Items = { ["CurrentUserId"] = User.Identity?.Name }
};
await model.ValidateIfValidatorExistsAsync(validationContext, serviceProvider);

Final Notes #

Choose the approach that fits your app type:

• For ASP.NET Core apps, the action filter enables hands-off auto-validation across all endpoints.
• For services/console apps, extension methods + DI resolution keep things flexible and explicit.
• Always use FluentValidation's built-in methods (like ValidateAndThrowAsync) to avoid reinventing error-handling logic.

内容的提问来源于stack exchange，提问作者Andrey Ravkov