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 میکند — انتزاعی که هیچ‌چیز پنهان نمی‌کند و فقط قابلیت‌ها را محدود میکند.