流利的验证将业务验证与验证验证划分

Question

我正在使用 ASP、CQRS + MediatR 和流畅的验证。我想实现用户角色验证，但不想将其与业务逻辑验证混合在一起。您知道如何实施吗？ 我的意思是必须针对特定请求执行特定的验证器。 有些东西告诉我解决方案在于 IEnumerable< IValidator>

{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators) => _validators = validators;

    public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
    {
        if (_validators.Any())
        {
            var context = new ValidationContext<TRequest>(request);
            var validationResults = await Task.WhenAll(_validators.Select(v => v.ValidateAsync(context, cancellationToken)));
            var failures = validationResults.SelectMany(r => r.Errors).Where(f => f != null).ToArray();

            if (failures.Any())
            {
                var errors = failures
                    .Select(x => new Error(x.ErrorMessage, x.ErrorCode))
                    .ToArray();
                throw new ValidationException(errors);
            }
        }

        return await next();
    }
}

Answer 1

我看到你的担心，我也发现自己处于这种情况。我想将验证器与处理程序分开，同时将它们保留在域/业务项目中。另外，我不想仅仅为了处理错误请求或任何其他自定义业务异常而引发异常。
你有正确的想法

我的意思是必须针对特定请求执行特定的验证器

为此，您需要设置一个调解器管道，因此对于每个命令您都可以找到适当的验证器，验证并决定是否执行该命令或返回失败的结果。

首先，创建一个 ICommand 接口（虽然不是必需的，但我就是这样做的），如下所示：

public interface ICommand<TResponse>: IRequest<TResponse>
{

}

并且，ICommandHandler 如下所示：

public interface ICommandHandler<in TCommand, TResponse>: IRequestHandler<TCommand, TResponse>
        where TCommand : ICommand<TResponse>
{

}

这样我们只能对命令应用验证。您不是继承 IRequest 和 IRequestHandler，而是从 ICommand 和 ICommandHandler 继承。

现在，按照我们之前商定的那样，为中介者创建一个 ValidationBehaviour。

public class ValidationBehaviour<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
    where TRequest : class, ICommand<TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehaviour(IEnumerable<IValidator<TRequest>> validators) => _validators = validators;

    public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
    {
        if (!_validators.Any())
            return await next();

        var validationContext = new ValidationContext<TRequest>(request);

        var errors = (await Task.WhenAll(_validators
            .Select(async x => await x.ValidateAsync(validationContext))))
            .SelectMany(x => x.Errors)
            .Where(x => x != null)
            .Select(x => x.CustomState)
            .Cast<TResponse>();

        //TResponse should be of type Result<T>

        if (errors.Any())
            return errors.First();

        try
        {
           return await next();
        }
        catch(Exception e)
        {
           //most likely internal server error
           //better retain error as an inner exception for debugging
           //but also return that an error occurred
           return Result<TResponse>.Failure(new InternalServerException(e));
        }
    }
}

这段代码很简单，构造函数中的所有验证器除外，因为您从程序集中注册了所有验证器，以便 DI 容器注入它们。
它等待所有验证来验证异步（因为我的验证主要需要调用数据库本身，例如获取用户角色等）。
然后检查错误并返回错误（这里我创建了一个 DTO 来包装我的错误和值以获得一致的结果）。
如果没有错误，只需让处理程序完成它的工作 return wait next();

现在，您必须注册此管道行为和所有验证器。
我使用 autofac，因此我可以通过以下方式轻松完成：

builder
       .RegisterAssemblyTypes(_assemblies.ToArray())
       .AsClosedTypesOf(typeof(IValidator<>))
       .AsImplementedInterfaces();
        var mediatrOpenTypes = new[]
        {
                typeof(IRequestHandler<,>),
                typeof(IRequestExceptionHandler<,,>),
                typeof(IRequestExceptionAction<,>),
                typeof(INotificationHandler<>),
                typeof(IPipelineBehavior<,>)
        };

        foreach (var mediatrOpenType in mediatrOpenTypes)
        {
            builder
                .RegisterAssemblyTypes(_assemblies.ToArray())
                .AsClosedTypesOf(mediatrOpenType)
                .AsImplementedInterfaces();
        }

如果您使用 Microsoft DI，则可以：

services.AddMediatR(typeof(Application.AssemblyReference).Assembly);
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));

services.AddValidatorsFromAssembly(typeof(Application.AssemblyReference).Assembly); //to add validators

示例用法：
我的通用 DTO 包装器

public class Result<T>: IResult<T>
{
    public Result(T? value, bool isSuccess, Exception? error)
    {
        IsSuccess = isSuccess;
        Value = value;
        Error = error;
    }

    public bool IsSuccess { get; set; }

    public T? Value { get; set; }
    public Exception? Error { get; set; }


    public static Result<T> Success(T value) => new (value, true, null);
    public static Result<T> Failure(Exception error) => new (default, false, error);
}

示例命令：

public record CreateNewRecordCommand(int UserId, string record) : ICommand<Result<bool>>;

它的验证器：

public class CreateNewRecordCommandValidator : AbstractValidator<CreateNewRecordCommand>
{
    public CreateNewVoucherCommandValidator(DbContext _context, IMediator mediator) //will be injected by out DI container
    {
          RuleFor(x => x.record)
            .NotEmpty()
            .WithState(x => Result<bool>.Failure(new Exception("Empty record")));
          //.WithName("record") if your validation a property in array or something and can't find appropriate property name

          RuleFor(x => x.UserId)
            .MustAsync(async(id, cToken) =>
             {
                   //var roles = await mediator.send(new GetUserRolesQuery(id, cToken));
                   //var roles = (await context.Set<User>.FirstAsync(user => user.id == id)).roles

                   //return roles.Contains(MyRolesEnum.CanCreateRecordRole);
             }
            )
            .WithState(x => Result<bool>.Failure(new MyCustomForbiddenRequestException(id)))
    }
}

这样您始终会获得结果对象，您可以检查 error 是否为 null 或 !IsSuccess，然后创建自定义Controller 库中的 HandleResult(result) 方法可以打开异常以返回 BadReuqestObjectResult(result) 或ForbiddenObjectResult（结果）。

如果您更喜欢抛出、捕获和处理管道中的异常，或者您不想使用非异步实现，请阅读此 https://code-maze.com/cqrs-mediatr-fluidation/
这样，您的所有验证都与处理程序相距甚远，同时保持结果一致。

Answer 2

我认为你最初的做法是正确的。当您说要将身份验证验证与其他业务验证分开时，您的意思是返回像 403 和 401 这样的 http 错误吗？
如果是这种情况，请尝试使用 和 接口标记身份验证验证以识别它们，并且不要立即运行所有验证。首先在集合中搜索使用该接口的验证，如果失败，则发送一个自定义异常，您可以在 IActionFilter 中标识该异常以设置所需的结果。这段代码并没有完全做到这一点，但你可以提出一个想法。

public class HttpResponseExceptionFilter : IActionFilter, IOrderedFilter
{
    private ISystemLogger _logger;
    public HttpResponseExceptionFilter()
    {
    }
    public int Order { get; } = int.MaxValue - 10;

    public void OnActionExecuting(ActionExecutingContext context) { }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        if (context.Exception is PipelineValidationException exception)
        {
            context.Result = new ObjectResult(new Response(false, exception.ValidationErrors.FirstOrDefault()?.ErrorMessage ?? I18n.UnknownError));
            context.ExceptionHandled = true;
        }
        else if (context.Exception != null)
        {
            _logger ??= (ISystemLogger)context.HttpContext.RequestServices.GetService(typeof(ISystemLogger));
            _logger?.LogException(this, context.Exception, methodName: context.HttpContext.Request.Method);
            context.Result = new ObjectResult(new Response(false, I18n.UnknownError));
            context.ExceptionHandled = true;
        }

    }
}