使用MediatR和FluentValidation实现CQRS应用程序的数据验证

本文主要是介绍使用MediatR和FluentValidation实现CQRS应用程序的数据验证，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

本文将重点介绍如何通过MediatR的管道功能将FluentValidation集成到项目中实现验证功能。

什么是CQRS？

CQRS（Command Query Responsibility Segregation）也叫命令查询职责分离，是近年来非常流行的应用程序架构模式。CQRS 背后的理念是在逻辑上将应用程序的流程分成两个独立的流程，即命令或查询。

命令用于改变应用程序的状态。对应CRUD的创建、更新和删除部分。查询用于检索应用程序中的信息，对应CRUD的读取部分。

CQRS 的优缺点

优点：

• 单一职责 – 命令和查询只有一个职责。要么更改应用程序的状态，要么检索它。因此它们很容易推理和理解。
• 解耦 – 命令或查询与其处理程序完全解耦，因此在处理程序方面有很大的灵活性，可以按照自己认为最合适的方式来实现。
• 可扩展性 – CQRS 模式在如何组织数据存储方面非常灵活，为您提供了多种可扩展性选择。您可以将一个数据库用于命令和
  查询。您可以使用独立的读/写数据库来提高性能，并在数据库之间使用消息传递或复制来实现同步。
• 可测试性 – 测试命令或查询处理程序非常简单，因为它们的设计非常简单，只执行一项任务。

缺点：

• 复杂性 – CQRS 是一种高级设计模式，您需要花时间才能完全理解它。它引入了很多复杂性，会给项目带来摩擦和潜在问题。在决定在项目中使用之前，请务必考虑清楚。
• 学习曲线 – 虽然 CQRS 看起来是一种简单明了的设计模式，但仍存在学习曲线。大多数开发人员习惯于用过程式（命令式）风格编写代码，而 CQRS 则与之大相径庭。
• 难以调试 – 由于命令和查询与其处理程序是分离的，因此应用程序没有自然的命令式流程。这使得它比传统应用程序更难调试。

使用 MediatR 的命令和查询

MediatR 使用接口（interface）来表示命令和查询。在我们的项目中，我们将为命令和查询创建单独的抽象。

首先，让我们看看接口是如何定义的：

using MediatR;
namespace Application.Abstractions.Messaging
{
    public interface ICommand<out TResponse> : IRequest<TResponse>
    {
    }
}

using MediatR;
namespace Application.Abstractions.Messaging
{
    public interface IQuery<out TResponse> : IRequest<TResponse>
    {
    }
}

我们在声明TResponse泛型时使用了 out 关键字，这表示它是协变的。这样，我们就可以使用比泛型参数指定的类型更多的派生类型。要了解有关协变和逆变的更多信息，请查看微软文档。

此外，为了完整起见，我们需要对命令和查询处理程序进行单独的抽象。

using MediatR;
namespace Application.Abstractions.Messaging
{
    public interface ICommandHandler<in TCommand, TResponse> : IRequestHandler<TCommand, TResponse>
        where TCommand : ICommand<TResponse>
    {
    }
}

using MediatR;
namespace Application.Abstractions.Messaging
{
    public interface IQueryHandler<in TQuery, TResponse> : IRequestHandler<TQuery, TResponse>
        where TQuery : IQuery<TResponse>
    {
    }
}

这里留下一个小问题，MediatR已经提供了IRequest和IRequest<TResponse>两个接口，那我们为什么还要再次定义IQuery<out TResponse>和ICommand<out TResponse>呢？

使用FluentValidation进行验证

FluentValidation 库允许我们轻松地为我们的类定义非常丰富的自定义验证。由于我们正在实现 CQRS，所以这里我们仅讨论对Command进行验证。由于Query对象仅仅是从应用程序获取数据，意思我们不必多此一举为Query设计验证器。

我们先设计一个UpdateUserCommand

public sealed record UpdateUserCommand(int UserId, string FirstName, string LastName) : ICommand<Unit>;

Unit是MediatR定义的一个特殊类，表示请求不返回数据，相当于void或Task。

这个命令将用于更新已有用户（通过UserId查找）的FirstName和LastName，关于MediatR如何新增、查询和修改数据，在之前的文章中我们已经介绍过了，这里不再赘述。

接下来我们需要为UpdateUserCommand定义一个验证器：

public sealed class UpdateUserCommandValidator : AbstractValidator<UpdateUserCommand>
{
    public UpdateUserCommandValidator()
    {
        RuleFor(x => x.UserId).NotEmpty();
        RuleFor(x => x.FirstName).NotEmpty().MaximumLength(100);
        RuleFor(x => x.LastName).NotEmpty().MaximumLength(100);
    }
}

此验证器将对UpdateUserCommand的属性进行以下验证：

• UserId - 不可空
• FirstName - 不可空且最大长度不超过100个字符
• LastName - 不可空且最大长度不超过100个字符

使用 MediatR PipelineBehavior创建装饰器

CQRS 模式使用命令和查询来传达信息并接收响应。实质上是请求-响应管道。这使我们能够轻松地围绕通过管道的每个请求引入其他行为，而无需实际修改原始请求。

您可能熟悉这种名为装饰器模式的技术。使用装饰器模式的典型例子就是ASP.NET Core中间件。MediatR与中间件的概念类似，称为：IPipelineBehavior

public interface IPipelineBehavior<in TRequest, TResponse> where TRequest : notnull
{
    Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next);
}

PipelineBehavior是请求实例的包装器，在如何实现它方面为您提供了很大的灵活性。PipelineBehavior非常适合应用程序中的横切关注点。横切关注点的很好的例子是日志记录、缓存，当然还有验证！

创建验证PipelineBehavior

为了在 CQRS 管道中实现验证，我们将使用刚才谈到的概念，即 MediatR 的 IPipelineBehavior 和 FluentValidation。

首先我们创建一个ValidationBehavior

public sealed class ValidationBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
    where TRequest : class, ICommand<TResponse>
{
    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())
        {
            return await next();
        }
        var context = new ValidationContext<TRequest>(request);
        var errorsDictionary = _validators
            .Select(x => x.Validate(context))
            .SelectMany(x => x.Errors)
            .Where(x => x != null)
            .GroupBy(
                x => x.PropertyName,
                x => x.ErrorMessage,
                (propertyName, errorMessages) => new
                {
                    Key = propertyName,
                    Values = errorMessages.Distinct().ToArray()
                })
            .ToDictionary(x => x.Key, x => x.Values);
        if (errorsDictionary.Any())
        {
            throw new ValidationException(errorsDictionary);
        }
        return await next();
    }
}

处理验证异常

为了处理遇到验证错误时抛出的ValidationException，我们可以使用 ASP.NET Core的 IMiddleware接口。

internal sealed class ExceptionHandlingMiddleware : IMiddleware
{
    private readonly ILogger<ExceptionHandlingMiddleware> _logger;
    
    public ExceptionHandlingMiddleware(ILogger<ExceptionHandlingMiddleware> logger) => _logger = logger;
    
    public async Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
        try
        {
            await next(context);
        }
        catch (Exception e)
        {
            _logger.LogError(e, e.Message);
            await HandleExceptionAsync(context, e);
        }
    }
    
    private static async Task HandleExceptionAsync(HttpContext httpContext, Exception exception)
    {
        var statusCode = GetStatusCode(exception);
        var response = new
        {
            title = GetTitle(exception),
            status = statusCode,
            detail = exception.Message,
            errors = GetErrors(exception)
        };
        httpContext.Response.ContentType = "application/json";
        httpContext.Response.StatusCode = statusCode;
        await httpContext.Response.WriteAsync(JsonSerializer.Serialize(response));
    }
    private static int GetStatusCode(Exception exception) =>
        exception switch
        {
            BadRequestException => StatusCodes.Status400BadRequest,
            NotFoundException => StatusCodes.Status404NotFound,
            ValidationException => StatusCodes.Status422UnprocessableEnttity,
            _ => StatusCodes.Status500InternalServerError
        };
    private static string GetTitle(Exception exception) =>
        exception switch
        {
            ApplicationException applicationException => applicationException.Title,
            _ => "Server Error"
        };
    private static IReadOnlyDictionary<string, string[]> GetErrors(Exception exception)
    {
        IReadOnlyDictionary<string, string[]> errors = null;
        if (exception is ValidationException validationException)
        {
            errors = validationException.ErrorsDictionary;
        }
        return errors;
    }
}

设置依赖注入

在运行应用程序之前，我们需要确保已向 DI 容器注册了所有服务。MediatR的DI注入方式之前已经介绍过，这里主要演示FluentValidation的注入。由于ValidationBehavior依赖IValidator<T>，因此需要注入我们定义的Validator。

// 在Startup.cs中配置
services.AddValidatorsFromAssembly(typeof(Application.AssemblyReference).Assembly);

// 在Program.cs中配置(≥ net 6.0)
builder.Services.AddValidatorsFromAssembly(typeof(Application.AssemblyReference).Assembly);

最后我们需要将ExceptionHandlingMiddleware也注册到DI容器和ASP.NET Core的管道中：

// 在Startup.cs中配置
services.AddTransient<ExceptionHandlingMiddleware>();

// 在Program.cs中配置(≥ net 6.0)
builder.Services.AddTransient<ExceptionHandlingMiddleware>();

app.UseMiddleware<ExceptionHandlingMiddleware>();

测试验证管道

在项目的Controllers文件夹中找到UserController：

/// <summary>
/// The users controller.
/// </summary>
[ApiController]
[Route("api/[controller]")]
public sealed class UsersController : ControllerBase
{
    private readonly ISender _sender;
    
    /// <summary>
    /// Initializes a new instance of the <see cref="UsersController"/> class.
    /// </summary>
    /// <param name="sender"></param>
    public UsersController(ISender sender) => _sender = sender;
    
    /// <summary>
    /// Updates the user with the specified identifier based on the specified request, if it exists.
    /// </summary>
    /// <param name="userId">The user identifier.</param>
    /// <param name="request">The update user request.</param>
    /// <param name="cancellationToken">The cancellation token.</param>
    /// <returns>No content.</returns>
    [HttpPut("{userId:int}")]
    public async Task<IActionResult> UpdateUser(int userId, [FromBody] UpdateUserRequest request, CancellationToken cancellationToken)
    {
        var command = request.Adapt<UpdateUserCommand>() with
        {
            UserId = userId
        };
        await _sender.Send(command, cancellationToken);
        return NoContent();
    }
}

我们可以看到，UpdateUser 操作非常简单，它从路由中获取用户Id，从请求正文中获取FirstName和LastName，然后创建一个新的 UpdateUserCommand实例并且通过管道发送命令。最后返回204（请求成功但无响应内容）状态码。

接下来我们通过Swagger调用API接口：

可以看到，请求的FirstName和LastName都是空白字符串。

补充内容之后再次发送请求。

结论

在本文中，我们介绍了CQRS 模式的一些更高级的概念，以及如何在应用程序中通过横切的方式实现数据验证，同时也简单的介绍了如何通过ASP.NTE Core的中间件实现全局异常处理。

---

点关注，不迷路。

如果您喜欢这篇文章，请不要忘记点赞、关注、转发，谢谢！如果您有任何高见，欢迎在评论区留言讨论……

这篇关于使用MediatR和FluentValidation实现CQRS应用程序的数据验证的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！