🚀 جادوی Minimal API در دات‌نت؛ فراتر از کد کمتر!

پاسخ کامل و عمیق:
مینیمال ای‌پی‌آی (Minimal API) در دات‌نت ۶ به بعد، فقط یک روش برای "کمتر کد زدن" نیست؛ بلکه یک تغییر معماری برای کاهش سربار (Overhead) و افزایش پرفورمنس است. در معماری سنتی مبتنی بر Controller، هر درخواست از فیلترهای متعدد، مدل‌بایندینگ‌های سنگین و لایه‌های انتزاعی عبور می‌کنه که برای APIهای بزرگ عالیه، اما برای سرویس‌های سبک یا پرترافیک، سربار غیرضروری ایجاد می‌کنه.

در Minimal API، ما مستقیماً با WebApplication و هندلرهای lambda کار می‌کنیم. این یعنی حذف رفلکشن‌های سنگین زمان اجرا، کنترل دقیق‌تر روی پایپ‌لاین درخواست و کاهش مصرف حافظه. اما نکته کلیدی اینجاست: مینیمال به معنای حذف ساختار نیست. شما همچنان می‌تونید از Dependency Injection، Validation، Filters و Middleware استفاده کنید، فقط بدون نیاز به کلاس‌های Controller verbose.

قصد مصاحبه‌گر:
مصاحبه‌گر با این سوال می‌خواد عمق درک شما رو بسنجه:
۱. آیا تریدآف‌ها رو می‌شناسید؟ کی باید از Controller استفاده کنید و کی Minimal API؟ (مثلاً برای پروژه‌های بزرگ تیمی، Controller هنوز خواناتر است).
۲. آیا با پرفورمنس درگیر بودید؟ آیا می‌دونید حذف Controller چقدر می‌تونه در RPS (Requests Per Second) تاثیر بذاره؟
۳. آیا می‌تونید کد تمیز بنویسید؟ خطر Minimal API این است که اگر درست ساختاردهی نشه، فایل Program.cs به یک "God Class" تبدیل میشه.

مثال‌های کاربردی و واقعی:
۱. سناریوی هندلینگ وب‌هوک (Webhook Handler):
در پروژه‌ای که روی درگاه پرداخت کار می‌کردیم، سرویسی داشتیم که روزانه میلیون‌ها نوتیفیکیشن از بانک دریافت می‌کرد. این اندپوینت فقط یک امضا رو چک می‌کرد و یک رکورد ساده می‌نوشت. استفاده از Controller و مدل‌بایندینگ سنگین دات‌نت، باعث تاخیر میلی‌ثانیه‌ای می‌شد که در مجموع قابل توجه بود. با مهاجرت به Minimal API**، توانستیم مستقیماً به `HttpRequest` دسترسی داشته باشیم، بادی رو استریم کنیم و پرفورمنس رو ۳۰٪ بهبود بدیم.

۲. **سناریوی لایه BFF (Backend for Frontend):
برای یک اپلیکیشن موبایل، نیاز به یک لایه واسط داشتیم که داده‌ها رو از چندین میکروسرویس بگیره، ترکیب کنه و به فرمت مخصوص موبایل برگردونه. چون منطق بیزینسی پیچیده‌ای نداشت و بیشتر تمرکز روی Aggregation بود، از Minimal API استفاده کردیم. این کار باعث شد بتونیم اندپوینت‌ها رو بسیار سریع پروتوتایپ کنیم و بدون درگیر شدن با ساختار کلاس‌های Controller، مستقیماً سرویس‌ها رو inject کنیم و خروجی رو بسازیم.

نمونه کد استاندارد:

var builder = WebApplication.CreateBuilder(args);

// ثبت سرویس‌ها در DI Container
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddValidators();

var app = builder.Build();

// اندپوینت ثبت سفارش با اعتبارسنجی و تزریق وابستگی
app.MapPost("/orders", async (CreateOrderDto dto, IOrderService service) => 
{
    // اعتبارسنجی دستی یا با فلوترها
    if (dto.Amount <= 0) 
        return Results.BadRequest("Invalid amount");

    var order = await service.CreateAsync(dto);
    return Results.Created($"/orders/{order.Id}", order);
})
.WithName("CreateOrder")
.WithOpenApi(); // پشتیبانی از Swagger

app.Run();

نکات کلیدی:
- ✅ ساختاردهی مهم است: برای پروژه‌های بزرگ، کدهای Minimal API را به فایل‌های جداگانه (Extension Methods) منتقل کنید تا Program.cs شلوغ نشود.
- ✅ پرفورمنس بالاتر: به دلیل حذف رفلکشن‌های Controller، در بارهای سنگین عملکرد بهتری دارد.
- ✅ انعطاف‌پذیری: دسترسی مستقیم به HttpContext و HttpRequest برای سناریوهای خاص فراهم است.
- ✅ مناسب میکروسرویس: برای سرویس‌های کوچک و تک‌منظوره (Single Responsibility) گزینه ایده‌آلی است.

----
برای مطالب بیشتر عضو کانال ما شوید:
t.me/brain_bytes

#برنامه_نویسی #مصاحبه_شغلی #دات_نت #MinimalAPI #ASPNETCore #معماری_نرم_افزار #پرفورمنس #کدنویسی_تمیز #استخدام_برنامه_نویس #تکنولوژی