.NET 6開發(fā)TodoList應用之實現(xiàn)接口請求驗證
需求
在響應請求處理的過程中，我們經(jīng)常需要對請求參數(shù)的合法性進行校驗，如果參數(shù)不合法，將不繼續(xù)進行業(yè)務邏輯的處理。我們當然可以將每個接口的參數(shù)校驗邏輯寫到對應的Handle方法中，但是更好的做法是借助MediatR提供的特性，將這部分與實際業(yè)務邏輯無關的代碼整理到單獨的地方進行管理。
為了實現(xiàn)這個需求，我們需要結(jié)合FluentValidation和MediatR提供的特性。
目標
將請求的參數(shù)校驗邏輯從CQRS的Handler中分離到MediatR的Pipeline框架中處理。
原理與思路
MediatR不僅提供了用于實現(xiàn)CQRS的框架，還提供了IPipelineBehavior<TRequest, TResult>接口用于實現(xiàn)CQRS響應之前進行一系列的與實際業(yè)務邏輯不緊密相關的特性，諸如請求日志、參數(shù)校驗、異常處理、授權(quán)、性能監(jiān)控等等功能。
在本文中我們將結(jié)合FluentValidation和IPipelineBehavior<TRequest, TResult>實現(xiàn)對請求參數(shù)的校驗功能。
實現(xiàn)
添加MediatR參數(shù)校驗Pipeline Behavior框架支持#
首先向Application項目中引入FluentValidation.DependencyInjectionExtensionsNuget包。為了抽象所有的校驗異常，先創(chuàng)建ValidationException類：
ValidationException.cs
namespace TodoList.Application.Common.Exceptions;
public class ValidationException : Exception
{
public ValidationException() : base("One or more validation failures have occurred.")
{
}
public ValidationException(string failures)
: base(failures)
{
}
}
參數(shù)校驗的基礎框架我們創(chuàng)建到Application/Common/Behaviors/中：
ValidationBehaviour.cs
using FluentValidation;
using FluentValidation.Results;
using MediatR;
using ValidationException = TodoList.Application.Common.Exceptions.ValidationException;
namespace TodoList.Application.Common.Behaviors;
public class ValidationBehaviour<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
where TRequest : notnull
{
private readonly IEnumerable<IValidator<TRequest>> _validators;
// 注入所有自定義的Validators
public ValidationBehaviour(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
.Where(r => r.Errors.Any())
.SelectMany(r => r.Errors)
.ToList();
// 如果有validator校驗失敗，拋出異常，這里的異常是我們自定義的包裝類型
if (failures.Any())
throw new ValidationException(GetValidationErrorMessage(failures));
}
return await next();
}
// 格式化校驗失敗消息
private string GetValidationErrorMessage(IEnumerable<ValidationFailure> failures)
{
var failureDict = failures
.GroupBy(e => e.PropertyName, e => e.ErrorMessage)
.ToDictionary(failureGroup => failureGroup.Key, failureGroup => failureGroup.ToArray());
return string.Join(";", failureDict.Select(kv => kv.Key + ": " + string.Join(' ', kv.Value.ToArray())));
}
}
在DependencyInjection中進行依賴注入：
DependencyInjection.cs
// 省略其他...
services.AddValidatorsFromAssembly(Assembly.GetExecutingAssembly());
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehaviour<,>)
添加Validation Pipeline Behavior
接下來我們以添加TodoItem接口為例，在Application/TodoItems/CreateTodoItem/中創(chuàng)建CreateTodoItemCommandValidator：
CreateTodoItemCommandValidator.cs
using FluentValidation;
using Microsoft.EntityFrameworkCore;
using TodoList.Application.Common.Interfaces;
using TodoList.Domain.Entities;
namespace TodoList.Application.TodoItems.Commands.CreateTodoItem;
public class CreateTodoItemCommandValidator : AbstractValidator<CreateTodoItemCommand>
{
private readonly IRepository<TodoItem> _repository;
public CreateTodoItemCommandValidator(IRepository<TodoItem> repository)
{
_repository = repository;
// 我們把最大長度限制到10，以便更好地驗證這個校驗
// 更多的用法請參考FluentValidation官方文檔
RuleFor(v => v.Title)
.MaximumLength(10).WithMessage("TodoItem title must not exceed 10 characters.").WithSeverity(Severity.Warning)
.NotEmpty().WithMessage("Title is required.").WithSeverity(Severity.Error)
.MustAsync(BeUniqueTitle).WithMessage("The specified title already exists.").WithSeverity(Severity.Warning);
}
public async Task<bool> BeUniqueTitle(string title, CancellationToken cancellationToken)
{
return await _repository.GetAsQueryable().AllAsync(l => l.Title != title, cancellationToken);
}
}
其他接口的參數(shù)校驗添加方法與此類似，不再繼續(xù)演示。
驗證
啟動Api項目，我們用一個校驗會失敗的請求去創(chuàng)建TodoItem：
請求
響應
因為之前測試的時候已經(jīng)在沒有加校驗的時候用同樣的請求生成了一個TodoItem，所以校驗失敗的消息里有兩項校驗都沒有滿足。
一點擴展
我們在前文中說了使用MediatR的PipelineBehavior可以實現(xiàn)在CQRS請求前執(zhí)行一些邏輯，其中就包含了日志記錄，這里就把實現(xiàn)方式也放在下面，在這里我們使用的是Pipeline里的IRequestPreProcessor<TRequest>接口實現(xiàn)，因為只關心請求處理前的信息，如果關心請求處理返回后的信息，那么和前文一樣，需要實現(xiàn)IPipelineBehavior<TRequest, TResponse>接口并在Handle中返回response對象：
// 省略其他...
var response = await next();
//Response
_logger.LogInformation($"Handled {typeof(TResponse).Name}");
return response;
創(chuàng)建一個LoggingBehavior：
using System.Reflection;
using MediatR.Pipeline;
using Microsoft.Extensions.Logging;
public class LoggingBehaviour<TRequest> : IRequestPreProcessor<TRequest> where TRequest : notnull
{
private readonly ILogger<LoggingBehaviour<TRequest>> _logger;
// 在構(gòu)造函數(shù)中后面我們還可以注入類似ICurrentUser和IIdentity相關的對象進行日志輸出
public LoggingBehaviour(ILogger<LoggingBehaviour<TRequest>> logger)
{
_logger = logger;
}
public async Task Process(TRequest request, CancellationToken cancellationToken)
{
// 你可以在這里log關于請求的任何信息
_logger.LogInformation($"Handling {typeof(TRequest).Name}");
IList<PropertyInfo> props = new List<PropertyInfo>(request.GetType().GetProperties());
foreach (var prop in props)
{
var propValue = prop.GetValue(request, null);
_logger.LogInformation("{Property} : {@Value}", prop.Name, propValue);
}
}
}
如果是實現(xiàn)IPipelineBehavior<TRequest, TResponse>接口，最后注入即可。
// 省略其他... services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehaviour<,>));
如果實現(xiàn)IRequestPreProcessor<TRequest>接口，則不需要再進行注入。
效果如下圖所示：
可以看到日志中已經(jīng)輸出了Command名稱和請求參數(shù)字段值。
總結(jié)
在本文中我們通過FluentValidation和MediatR實現(xiàn)了不侵入業(yè)務代碼的請求參數(shù)校驗邏輯，在下一篇文章中我們將介紹.NET開發(fā)中會經(jīng)常用到的ActionFilters。
參考資料
How to use MediatR Pipeline Behaviours?
到此這篇關于.NET 6開發(fā)TodoList應用之實現(xiàn)接口請求驗證的文章就介紹到這了,更多相關.NET 6接口請求驗證內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
這些代碼全部寫在和頁面分離的代碼頁中(codebehind),如果要嵌入到*.aspx頁面,可能會出現(xiàn)問題.2008-11-11
GridView自帶了數(shù)據(jù)排序功能。在設計視圖下，只能對GridView的排序數(shù)據(jù)列和排序方向進行靜態(tài)設置。在后臺程序中，則需要用Attributes方式對GridView的這兩個屬性進行動態(tài)設置2014-01-01
一個ASP.Net下的WebShell，主要完成cmd命令。一般的服務器設置，asp.net用戶的權(quán)限都比較高。如果asp的webshell無法執(zhí)行，可能asp.net的可以執(zhí)行。2013-07-07
這篇文章介紹了ASP.NET?Core使用自定義日志中間件的方法，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-04-04
gridview指定某一列滾動的asp.net實現(xiàn)代碼。2009-11-11
這篇文章主要介紹了.NET性能優(yōu)化之為集合類型設置初始大小的方法,今天要談的一個性能優(yōu)化的Tips是一個老生常談的點，但是也是很多人沒有注意的一個點。在使用集合類型是，你應該設置一個預估的初始大小，那么為什么需要這樣做？我們一起來從源碼的角度說一說2022-05-05
這篇文章主要介紹了列舉ASP.NET 頁面之間傳遞值的幾種方式，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2019-03-03
使用 ServiceStack.Text 序列化 json的實現(xiàn)代碼
今天發(fā)篇文章總結(jié)下自己使用 ServiceStack.Text 來序列化 json。它的速度比 Newtonsoft.Json 快很多，在測試時發(fā)現(xiàn)比 fastJson 還快些2013-06-06
這篇文章介紹了.Net Core日志記錄之自定義日志組件，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-06-06
在 ASP.Net Core 中使用 MiniProfiler的方法
這篇文章主要介紹了在 ASP.Net Core 中使用 MiniProfiler的方法,本文給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-03-03