CodeShot
Midسختی 3 از ۵· در 68٪ مصاحبه‌های این حوزه پرسیده شده

Repository Pattern چیست و آیا با EF Core هم به آن نیاز داریم؟

نشان کردن

پاسخ کوتاه

الگویی که دسترسی به داده را پشت یک Interface پنهان می‌کند. با EF Core استفاده از آن اختیاری است، چون خود `DbSet` نقش Repository و `DbContext` نقش Unit of Work را دارد.

پاسخ کامل

Repository دو هدف دارد: پنهان‌کردن جزئیات دیتابیس و ساده‌کردن تست.

بحث اصلی در مصاحبه‌ها این است که آیا روی EF Core لازم است یا نه:

موافق: لایه Application به EF Core وابسته نمی‌شود، کوئری‌های پیچیده در یک جا جمع می‌شوند، و تست‌نویسی با یک Fake ساده‌تر از Mock کردن IQueryable است.

مخالف: DbSet<T> خودش Repository است و DbContext خودش Unit of Work؛ یک Generic Repository روی آن معمولاً فقط قابلیت‌ها را کم می‌کند (مثلاً Include یا AsSplitQuery از دست می‌رود).

جمع‌بندی عملی: Repositoryهای اختصاصی و سبک بنویسید، نه Repository<T> عمومی. در این پروژه چون لایه داده Dapper + Stored Procedure است، Repository اجتناب‌ناپذیر و کاملاً موجه است.

مثال کد

// ❌ عمومی و بی‌فایده
public interface IRepository<T> { Task<T?> GetByIdAsync(Guid id); }

// ✅ اختصاصی و معنادار
public interface ICapsuleRepository
{
    Task<Capsule?> GetBySlugAsync(string slug, CancellationToken ct = default);
    Task<IReadOnlyList<Capsule>> GetRelatedAsync(Guid conceptId, Guid excludeId, int take = 5, CancellationToken ct = default);
}

نکته مهم

اگر لایه داده شما Dapper یا Stored Procedure است، بحث «EF خودش Repository دارد» اصلاً موضوعیت ندارد.

اشتباه رایج

❌ ساختن Repository<T> عمومی که فقط متدهای DbSet را Wrap می‌کند — انتزاعی که هیچ‌چیز پنهان نمی‌کند و فقط قابلیت‌ها را محدود می‌کند.

شرکت‌هایی که این سؤال را پرسیده‌اند

اسنپ