🛠ساخت یک پروژه جاه‌طلبانه‌تر با Aspire

شما حتی می‌توانید یک Aspire AppHost را فقط در یک فایل بسازید—که اگر خوب فکر کنید واقعاً چیز عجیبی است:

#:sdk Aspire.AppHost.Sdk@13.0.0
#:package Aspire.Hosting.AppHost@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache")
    .WithDataVolume();

var postgres = builder.AddPostgres("postgres")
    .WithDataVolume()
    .AddDatabase("tododb");

var todoApi = builder.AddProject<Projects.TodoApi>("api")
    .WithReference(cache)
    .WithReference(postgres);

builder.AddNpmApp("frontend", "../TodoApp")
    .WithReference(todoApi)
    .WithReference("api")
    .WithHttpEndpoint(env: "PORT")
    .WithExternalHttpEndpoints();

builder.Build().Run();

با استفاده از دستور #:sdk Aspire.AppHost.Sdk@13.0.0، فایل تک‌ستونه‌ی شما تبدیل به یک orchestrator کامل برای یک distributed application می‌شود. شما در حال تعریف زیرساخت، اتصال وابستگی‌ها، و راه‌اندازی یک محیط توسعه‌ی کامل هستید—بدون اینکه هیچ فایل project بسازید.

این قابلیت به‌ویژه زمانی کاربردی است که دارید معماری را prototype می‌کنید یا لازم دارید خیلی سریع یک محیط تست بالا بیاورید.

Migrating to a Full Project 🚀 — مهاجرت به یک پروژه‌ی کامل

در نهایت، بعضی اسکریپت‌ها از ریشه‌ی تک‌فایلی خود بزرگ‌تر می‌شوند. شاید لازم باشد چیزها را به چند فایل تقسیم کنید، یا شاید بخواهید پشتیبانی کامل IDE برای Debugging داشته باشید. این انتقال بدون دردسر است:

dotnet project convert MyUtility.cs

این دستور یک ساختار پروژه‌ی کامل ایجاد می‌کند، درحالی‌که تمام package reference‌ها و انتخاب‌های SDK شما را حفظ می‌کند. کد شما به Program.cs منتقل می‌شود و یک .csproj دریافت می‌کنید که تمام آن #:directiveهایی را که استفاده کرده بودید منعکس می‌کند. 📦⚙️

Current Limitations ⚠️ — محدودیت‌های فعلی

در حال حاضر، این قابلیت کاملاً تک‌فایلی است. اگر به چند فایل نیاز دارید، باید تا NET 11. صبر کنید یا پروژه را تبدیل کنید. البته همچنان می‌توانید به پروژه‌ها و packageهای دیگر reference بدهید، اما فایل اصلی اسکریپت باید تنها یک فایل باشد. 📄

مکانیزم caching ممکن است گاهی دچار سردرگمی شود، مخصوصاً اگر سریع روی نسخه‌های package تکرار کنید. و با اینکه پشتیبانی IDE بهتر شده، هنوز به سطح پروژه‌های کامل نرسیده است—به‌خصوص برای IntelliSense مربوط به packageهایی که به صورت داینامیک reference می‌کنید. 💡

اما برای کاری که طراحی شده است (قابل‌دسترس‌تر کردن #C برای سناریوهای scripting)، به‌طرز شگفت‌انگیزی خوب عمل می‌کند. می‌توانید از آن برای build scriptها، کارهای یک‌باره‌ی data migration، تست سریع API، یا حتی آموزش #C بدون اینکه روز اول بخواهید ساختار یک solution را توضیح بدهید، استفاده کنید. 🧪⚙️

Where This Leaves Us 🎯 — نتیجه‌ی این قابلیت

File-based app
ها حسی ایجاد می‌کنند شبیه اینکه #C بالاخره پذیرفته است که همه‌چیز قرار نیست یک برنامه‌ی enterprise باشد. گاهی لازم دارید یک فایل log را parse کنید، گاهی باید سریع یک الگوریتم را تست کنید، و گاهی دارید برنامه‌نویسی را به کسی آموزش می‌دهید و نمی‌خواهید روز اول برایش از solution file حرف بزنید. 📝⚡️

این قابلیت انقلابی در توسعه‌ی #C ایجاد نمی‌کند، اما شکاف آزاردهنده‌ای را پر می‌کند که سال‌ها توسعه‌دهندگان را اذیت کرده بود. اگر تا امروز یک پوشه پر از اسکریپت‌های سریع داشتید چون #C برای چنین کارهایی سنگین به نظر می‌رسید، شاید وقتش رسیده دوباره به زبان محبوبتان شانس بدهید. 💙🤖

در نهایت، بهترین زبان برای یک اسکریپت سریع، همان زبانی است که از قبل بلد هستید—و حالا #C در این زمینه بسیار قانع‌کننده‌تر شده است. ⚡️💻