Entity Framework Core و اتصال به SQL Server

.NET 10 | EF Core 10، DbContext و Migrations

Entity Framework Core لایه نگاشت میان مدل شیءگرای .NET و ساختار رابطهای SQL Server است. DbContext واحد اصلی Tracking، Query و ذخیره تغییرات است و Migrationها تغییر Schema را نسخه‌بندی می‌کنند.

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

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

Entity Framework Core لایه نگاشت میان مدل شیءگرای .NET و ساختار رابطهای SQL Server است. DbContext واحد اصلی Tracking، Query و ذخیره تغییرات است و Migrationها تغییر Schema را نسخه‌بندی می‌کنند.

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

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

Connection String از Configuration خوانده و DbContext با AddDbContext ثبت می‌شود. Context معمولاً Scoped است و در Serviceهای همان Request مصرف می‌شود. Secretهای اتصال نباید در Source Control ذخیره شوند.

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("DefaultConnection"));
});

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

پس از تعریف Product و AppDbContext، Migration اولیه ساخته و روی دیتابیس اعمال می‌شود. Migration باید در محیط کنترل‌شده تولید و پیش از Production بازبینی شود.

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

dotnet ef migrations add InitialCreate
dotnet ef database update

// Query
var products = await db.Products
    .AsNoTracking()
    .OrderBy(p => p.Id)
    .ToListAsync(cancellationToken);

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

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

• DbContext به‌صورت Singleton نگهداری نشود.
• Connection String و Password از Secret Store یا Environment تأمین شوند.
• Migrationهای Production پیش از اجرا Review شوند.
• برای Queryهای Read-only از AsNoTracking استفاده شود.

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

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

• ساخت DbContext دستی در هر Method.
• اتصال مستقیم Controller به چند DbContext و منطق حجیم.
• اعتماد به EnsureCreated برای چرخه واقعی Migration.
• ثبت Secret در appsettings قابل Commit.

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

• Provider SQL Server نصب و ثبت شده است.
• DbContext از DI دریافت می‌شود.
• Migration قابل تولید و اعمال است.
• اتصال و خطای Certificate/Network به‌صورت قابل تشخیص مدیریت می‌شود.

7. جمع‌بندی

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