Тег: validation

Пошаговое руководство по замене написанных вручную if-проверок в обработчиках minimal API на ASP.NET Core 11 встроенным валидатором на основе DataAnnotations и генерации исходного кода: что ломается, какие ручные правила переносятся, а какие нет, и как убедиться, что контракт 400 ProblemDetails остаётся прежним.

Вызовите AddProblemDetails с колбэком CustomizeProblemDetails, чтобы изменить форму ответа 400, который встроенная валидация minimal API возвращает в ASP.NET Core 11: добавьте traceId, перепишите title, замените 400 на 422 или получите полный контроль с помощью собственного IProblemDetailsWriter.

Используйте встроенную валидацию на генераторе исходного кода для синхронных правил, выразимых атрибутами, в ASP.NET Core 11; обращайтесь к FluentValidation, когда нужны асинхронные правила, сложная логика между полями или валидация вне ваших моделей предметной области.

Главный источник расхождений в валидации между Blazor WebAssembly клиентом и ASP.NET Core API -- это соблазн писать правила дважды. Это руководство показывает единственную раскладку, которая масштабируется в .NET 11: библиотека классов Shared, владеющая DTO и их валидаторами, потребляемая и WASM клиентом (EditForm + DataAnnotationsValidator или Blazored.FluentValidation), и сервером (фильтр endpoint в minimal API или model binding в MVC), с протестированным циклом, который возвращает серверные ValidationProblemDetails обратно в EditContext.