استفاده از چند EF Core DbContext در یک برنامه

Entity Framework Core (EF Core)
یک ORM محبوب در NET. است که به شما امکان می‌دهد با پایگاه‌ داده‌های SQL کار کنید.

EF Core
از DbContext استفاده می‌کند که نمایانگر یک نشست (Session) با پایگاه داده است و مسئول ردیابی تغییرات، انجام عملیات دیتابیس و مدیریت اتصال‌های پایگاه داده می‌باشد.

به‌طور معمول، برای کل برنامه فقط یک DbContext استفاده می‌شود.
اما اگر نیاز داشته باشید چندین DbContext داشته باشید چه می‌کنید؟ 🤔

📍در این مطلب بررسی می‌کنیم:

• چه زمانی ممکن است بخواهید از چندین DbContext استفاده کنید؟

• چطور چندین DbContext ایجاد کنیم؟

• مزایای استفاده از چندین DbContext؟

📌 چرا از چندین DbContext استفاده کنیم؟

1️⃣ چندین پایگاه داده
اگر برنامه شما باید با چندین دیتابیس SQL کار کند، مجبورید از چندین DbContext استفاده کنید که هر کدام مختص یک دیتابیس مشخص هستند.

2️⃣ تفکیک مسئولیت‌ها
اگر مدل دامنه (Domain Model) برنامه شما پیچیده است، ممکن است با تفکیک وظایف بین چند DbContext عملکرد بهتری بگیرید؛ به طوری که هر DbContext مسئول یک بخش خاص از دامنه باشد.

3️⃣ معماری Modular Monolith
در این نوع معماری می‌توانید برای هر DbContext یک Schema متفاوت در پایگاه داده پیکربندی کنید تا جداسازی منطقی در سطح دیتابیس داشته باشید.

4️⃣ استفاده از Read Replicas
می‌توانید یک DbContext جداگانه برای دسترسی به Read Replica پایگاه داده تنظیم کنید و از آن فقط برای کوئری‌های خواندنی استفاده کنید. همچنین می‌توانید ویژگی QueryTrackingBehavior.NoTracking را برای آن فعال کنید تا عملکرد بهتری داشته باشید.

⚙️ ایجاد چندین DbContext در یک برنامه

فرض کنید در برنامه خود دو DbContext داریم:
• CatalogDbContext
• OrderDbContext

و می‌خواهیم شرایط زیر را رعایت کنیم:

• هر دو از یک دیتابیس استفاده کنند
• هر DbContext Schema متفاوتی داشته باشد

public class CatalogDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }
}

public class OrderDbContext : DbContext
{
    public DbSet<Order> Orders { get; set; }
    public DbSet<LineItem> LineItems { get; set; }
}

ابتدا باید DbContext‌ها را در DI Container پیکربندی کنیم:

services.AddDbContext<CatalogDbContext>(options =>
    options.UseSqlServer("CONNECTION_STRING"));

services.AddDbContext<OrderDbContext>(options =>
    options.UseSqlServer("CONNECTION_STRING"));

اگر هر دو در یک Schema باشند، همین کافی است.
اما اگر بخواهید Schema جداگانه داشته باشید، باید در متد OnModelCreating این مورد را مشخص کنید:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.HasDefaultSchema("catalog");
}

و برای DbContext دوم:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.HasDefaultSchema("order");
}

⚠️ محدودیت‌ها در استفاده از چندین DbContext

• جوین (Join) بین DbContext‌های مختلف ممکن نیست.

• تراکنش‌ها فقط زمانی کار می‌کنند که هر دو DbContext از یک دیتابیس استفاده کنند.

• اگر Schema‌های جدا دارید، باید جدول تاریخچه مایگریشن‌ها را نیز جداگانه تعریف کنید:

services.AddDbContext<CatalogDbContext>(options =>
    options.UseSqlServer(
        "CONNECTION_STRING",
        o => o.MigrationsHistoryTable(
            tableName: HistoryRepository.DefaultTableName,
            schema: "catalog")));

✅ مزایای استفاده از چندین DbContext

تفکیک مسئولیت‌ها → کد سازمان‌یافته‌تر و ماژولارتر

عملکرد بهتر → کاهش تداخل و بهبود همزمانی

کنترل و امنیت بیشتر → امکان تنظیم دسترسی دقیق‌تر

📝 جمع‌بندی
استفاده از چند DbContext در EF Core ساده و کاربردی است.

برای برنامه‌های Read-Heavy می‌توانید DbContext جداگانه‌ای بدون Query Tracking داشته باشید.

در معماری Modular Monolith می‌توانید DbContext‌ها را با Schema جداگانه پیکربندی کنید تا جداسازی منطقی در دیتابیس داشته باشید.

🔖هشتگ‌ها:
#DotNet #EFCore #CSharp #DbContext #ModularMonolith #EntityFramework #DatabaseDesign

⚔️ SQL vs NoSQL

SQL (پایگاه‌داده رابطه‌ای)

🗂 مدل داده: ساخت‌یافته و جدولی

📈 مقیاس‌پذیری: عمودی (Vertical Scaling)

🏗 ساختار (Schema): از قبل تعریف‌شده

✅ پشتیبانی ACID: قوی

🎯 مناسب برای: برنامه‌های تراکنشی

💻 نمونه‌ها: MySQL، PostgreSQL، Oracle

NoSQL (پایگاه‌داده غیررابطه‌ای)

🗂 مدل داده: انعطاف‌پذیر (سند، کلید-مقدار، گراف)

📈 مقیاس‌پذیری: افقی (Horizontal Scaling)

🏗 ساختار (Schema): پویا و بدون ساختار ثابت

✅ پشتیبانی ACID: محدود یا سازگاری تدریجی (Eventual Consistency)

🎯 مناسب برای: داده‌های حجیم (Big Data)، تحلیل‌های لحظه‌ای

💻 نمونه‌ها: MongoDB، Cassandra، Redis

🗂 پایگاه‌داده‌های محبوب NoSQL و کاربرد آن‌ها

MongoDB (مبتنی بر سند) → مدیریت محتوا، کاتالوگ محصولات

Redis (کلید-مقدار) → کشینگ، تحلیل‌های لحظه‌ای، ذخیره‌سازی نشست‌ها

Cassandra (مبتنی بر ستون‌ها) → داده‌های حجیم، سیستم‌های با دسترسی بالا

Neo4j (گراف) → شناسایی تقلب، شبکه‌های اجتماعی

💡 کاربردهای NoSQL

📊 برنامه‌های Big Data: ذخیره و پردازش مؤثر حجم‌های بسیار زیاد داده‌های غیرساخت‌یافته و نیمه‌ساخت‌یافته

⏱️ تحلیل‌های لحظه‌ای (Real-Time Analytics): پشتیبانی از کوئری‌های سریع و تحلیل داده برای موتورهای پیشنهاددهنده یا شناسایی تقلب

🌐 برنامه‌های وب مقیاس‌پذیر: مدیریت کاربران زیاد و ترافیک بالا با مقیاس‌پذیری افقی در بین سرورها

🔄 ذخیره‌سازی داده انعطاف‌پذیر: مدیریت فرمت‌های مختلف داده (JSON، کلید-مقدار، اسناد، گراف) بدون نیاز به ساختار سخت و ثابت

🔖هشتگ‌ها:
#NoSQL #SQL #Database #DatabaseDesign