Validation و اعتبارسنجی ورودی‌ها

.NET 10 | DataAnnotations، ProblemDetails و قواعد ورودی

Validation مرز میان داده نامعتبر و منطق برنامه است. قواعد شکل ورودی باید پیش از اجرای عملیات پرهزینه یا تغییر داده بررسی شوند و خطاها با قالب قابل پردازش به Client بازگردند.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

Validation مرز میان داده نامعتبر و منطق برنامه است. قواعد شکل ورودی باید پیش از اجرای عملیات پرهزینه یا تغییر داده بررسی شوند و خطاها با قالب قابل پردازش به Client بازگردند.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

2. ساختار پیشنهادی در پروژه

قواعد ساده Contract روی DTO قرار می‌گیرند. قواعد دامنه‌ای که به وضعیت سیستم وابسته‌اند در Service یا Domain بررسی می‌شوند. تفکیک این دو باعث می‌شود Validation صرفاً به Attributeها محدود نشود.

public sealed class CreateProductRequest
{
    [Required]
    [StringLength(120, MinimumLength = 2)]
    public string Name { get; init; } = string.Empty;

    [Range(0.01, 1_000_000_000)]
    public decimal Price { get; init; }
}

3. سناریوی اجرایی

اگر Name خالی یا Price خارج از محدوده باشد، درخواست باید پیش از ورود به منطق ایجاد Product رد شود. برای Conflictهایی مانند SKU تکراری، پاسخ 409 مناسب‌تر از 400 عمومی است.

در این سناریو، قرارداد ورودی و خروجی، مسیر شکست و رفتار قابل مشاهده سرویس باید پیش از جزئیات پیاده‌سازی مشخص شود. این رویکرد باعث می‌شود تغییرات بعدی بدون وابستگی پنهان و با امکان تست دقیق انجام شوند.

if (await _db.Products.AnyAsync(p => p.Sku == request.Sku, cancellationToken))
{
    return Conflict(new ProblemDetails
    {
        Title = "Duplicate SKU",
        Status = StatusCodes.Status409Conflict
    });
}

4. اصول طراحی و نگهداری

پیاده‌سازی قابل نگهداری تنها به درست کار کردن در مسیر موفق محدود نیست. مرزهای مسئولیت، قابلیت مشاهده، امنیت، رفتار در خطا و امکان توسعه تدریجی باید هم‌زمان بررسی شوند.

• Validation Contract و Business Validation از هم تفکیک شوند.
• پیام خطا شامل داده حساس یا جزئیات Stack Trace نباشد.
• قواعد مهم داده در صورت امکان در Database نیز enforce شوند.
• Validation سمت Client جای Validation سمت Server را نمی‌گیرد.

5. خطاهای رایج و کنترل آن‌ها

بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص می‌شود. موارد زیر باید در بازبینی کد و تست‌های قبل از انتشار کنترل شوند.

• اعتماد به Validation رابط کاربری.
• استفاده از 500 برای ورودی نامعتبر.
• وابسته کردن DTO API به Attributeهای Persistence.
• پیام‌های خطای مبهم و غیرقابل نگاشت به Field.

6. چک‌لیست نهایی فصل

• ورودی نامعتبر با 400 استاندارد پاسخ داده می‌شود.
• Conflictهای دامنه‌ای Code مناسب دارند.
• حد طول و Range برای ورودی‌های مهم تعریف شده است.
• قواعد یکپارچگی در چند لایه متناسب با مسئولیت enforce می‌شوند.

7. جمع‌بندی

مفاهیم این فصل زمانی کامل محسوب می‌شوند که هم مسیر موفق و هم مسیر خطا قابل پیش‌بینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.