شرح repository pattern در #C | معرفی جامع + نحوه ساخت

نوشته شده توسط: تیم فنی نیک آموز

تاریخ انتشار: ۲۱ اسفند ۱۴۰۳

آخرین بروزرسانی: 21 اسفند 1403

زمان مطالعه: 20 دقیقه

نرم افزارهای سازمانی هر لحظه در حال توسعه هستند، و بهینه‌سازی تعاملات با پایگاه داده‌ها یکی از چالش‌های مهم مهندسان نرم افزارهاست؛ تمام سیستم‌هایی که بر مبنای تحلیل داده عمل می‌کنند با حجم عظیمی از درخواست‌ها سروکار دارند که اگر به‌درستی مدیریت نشوند، کاهش کارایی و افزایش تأخیر (Latency) در پردازش داده‌ها را به دنبال خواهند داشت.

در معماری نرم ‌افزار، شرح repository pattern در #C یکی از الگوهای طراحی پیشرفته است که امکان جداسازی منطقی بین لایه دسترسی به داده‌ها (Data Access Layer) و لایه کسب‌وکار (Business Logic Layer) را فراهم می‌کند؛ این الگو یک واسط انتزاعی برای تعامل با داده‌ها درست کرده و از این طریق داده‌ها را بهتر مدیریت می‌کند. در اصل، این کار را با هدف جلوگیری از ایجاد وابستگی‌های ناخواسته انجام می‌دهند.

در این صفحه، به بررسی Repository Pattern در #C و نقش آن در افزایش کارایی داشبوردهای تحلیل داده می‌پردازیم؛ همچنین، مقایسه‌ای با سایر الگوهای مدیریت داده انجام می‌دهیم و راهکارهای بهینه‌سازی پردازش داده در این معماری را مرور می‌کنیم.

چرا از الگوی Repository Pattern استفاده کنیم؟

یکی از اصل‌های مهم در معماری نرم‌افزار، تفکیک نگرانی‌ها (Separation of Concerns) است که به کاهش پیچیدگی، بهبود خوانایی و قابلیت نگهداری کد کمک می‌کند. در بسیاری از پروژه‌ها، لایه کسب‌وکار مستقیماً به Entity Framework (EF) یا سایر ORMها وابسته است که منجر به وابستگی سخت (Tight Coupling) می‌شود و انعطاف‌پذیری سیستم را کاهش می‌دهد.

Repository Pattern با ایجاد یک لایهٔ انتزاعی (Abstraction Layer) بین بخش‌های کسب‌وکار و پایگاه داده، مزایای زیر را ارائه می‌دهد:

جداسازی EF Core از لایه کسب‌وکار: امکان تغییر ORM یا پایگاه داده بدون دست‌کاری لایهٔ کسب‌وکار.
افزایش قابلیت تست‌پذیری (Testability): امکان Mock کردن و انجام تست‌های واحد بدون نیاز به اتصال مستقیم به دیتابیس.
ایجاد یک واسط استاندارد برای مدیریت داده‌ها: پیاده‌سازی متدهای CRUD و جلوگیری از نوشتن کوئری‌های تکراری.

توجه: اگرچه این الگو در پروژه‌های بزرگ بسیار مفید است، اما در پروژه‌های کوچک می‌تواند منجر به پیچیدگی غیرضروری و کد اضافی (Boilerplate Code) شود. همچنین Repository Pattern به‌تنهایی تضمینی بر افزایش Performance ندارد؛ اما در پروژه‌های بزرگ می‌تواند با فراهم‌آوردن ساختار ماژولار، به پیاده‌سازی آسان‌تر مکانیزم‌های کش و مدیریت بهتر کوئری‌ها کمک کند.

الگوی Repository Pattern در #C: اصول، معماری و پیاده‌سازی پیشرفته

الگوی رپوزیتوری به‌عنوان یک الگوی طراحی پیشرفته، یک لایه واسطه برای بهبود عملیات پایگاه داده ارائه می‌دهد و موجب افزایش انعطاف‌پذیری، تست‌پذیری و کارایی سیستم‌های مبتنی بر #C و Entity Framework می‌شود.

در این بخش، معماری، پیاده‌سازی پیشرفته و بهینه‌سازی این الگو را بررسی می‌کنیم:

ضرورت استفاده از الگوی repository pattern در #C

یکی از اصل‌هایی که در معماری نرم افزاری امروز اهمیت دارد، اصل تفکیک نگرانی‌ها (Separation of Concerns) است؛ این کار به کاهش پیچیدگی، بهبود خوانایی و قابلیت نگهداری کد کمک می‌کند. در برنامه‌های داده‌محور، یکی از وابستگی مستقیم لایه‌های کسب‌وکار به Entity Framework) EF) یا سایر ORMها از رایج‌ترین مشکلات است که منجر به وابستگی سخت (Tight Coupling) و کاهش انعطاف‌پذیری سیستم می‌شود.

هدف استفاده از الگوی repository pattern در #C این است که این وابستگی را از بین برده و امکان تفکیک کامل منطق دسترسی به داده‌ها (Data Access Logic) از لایه کسب‌وکار را فراهم می‌کند. این الگو یک لایه انتزاعی (Abstraction Layer) بین بخش‌های کسب‌وکار و پایگاه داده ایجاد می‌کند که مزایای زیر را به همراه دارد:

جدا کردن EF Core از منطق کسب‌وکار: امکان تغییر پایگاه داده یا ORM بدون تغییر در لایه کسب‌وکار

افزایش قابلیت تست‌پذیری (Testability): استفاده از Mocking و Unit Testها بدون نیاز به اتصال به پایگاه داده

ایجاد یک واسط استاندارد برای دسترسی به داده‌ها: پیاده‌سازی متدهای عمومی CRUD و مدیریت پیشرفته داده

معماری Repository Pattern: طراحی انتزاعی و چندلایه

در یک پیاده‌سازی پیشرفته از Repository Pattern، از چندین لایه برای تفکیک منطق دسترسی به داده‌ها از سایر بخش‌های سیستم استفاده می‌شود:

لایه Entities: شامل مدل‌های داده‌ای که با پایگاه داده در ارتباط هستند.
لایه Repository: پیاده‌سازی واسط‌های مخزن و تعریف متدهای مربوط به CRUD.
لایه Unit of Work: مدیریت چندین Repository به‌صورت هم‌زمان برای اطمینان از تراکنش‌های یکپارچه.
لایه Service: شامل منطق کسب‌وکار و استفاده از Repositoryها.
لایه Presentation: رابط کاربری یا API که داده‌ها را از سرویس‌ها دریافت می‌کند.

نکته:
در پروژه‌های Enterprise-Grade، به‌جای استفاده از Repository Pattern ساده، ترکیب این الگو با CQRS) Command Query Responsibility Segregation) و UoW) Unit of Work) می‌تواند کارایی سیستم را افزایش دهد و پردازش‌های خواندنی و نوشتنی را از یکدیگر جدا کند.

پیاده‌سازی پیشرفته Repository Pattern در #C

ابتدا یک رابط (Interface) عمومی برای تمامی موجودیت‌ها (Entities) ایجاد می‌کنیم:

public interface IRepository<T> where T : class
{
       Task<T> GetByIdAsync(int id);
       Task<IEnumerable<T>> GetAllAsync();
       Task AddAsync(T entity);
       void Update(T entity);
       void Delete(T entity);
}

بهینه‌سازی:

متدهای CRUD را به‌صورت(Asynchronous) پیاده‌سازی کرده‌ایم تا عملکرد I/O پایگاه داده بهینه شود.
به‌ جای Delete(int id) از Delete(T entity) استفاده کرده‌ایم تا وابستگی مستقیم به کلید اصلی کاهش یابد.

اکنون کلاس Repository را که این رابط را پیاده‌سازی می‌کند، ایجاد می‌کنیم:

public class Repository<T> : IRepository<T> where T : class
{
       protected readonly DbContext _context;
       private readonly DbSet<T> _dbSet;
       public Repository(DbContext context)
{
       _context = context;
        _dbSet = context.Set<T>();
       }
       public async Task<T> GetByIdAsync(int id)
       {
       return await _dbSet.FindAsync(id);
       }
       public async Task<IEnumerable<T>> GetAllAsync()
       {
       return await _dbSet.ToListAsync();
       }
       public async Task AddAsync(T entity)
       {
       await _dbSet.AddAsync(entity);
       }
       public void Update(T entity)
       {
       _dbSet.Attach(entity);
       _context.Entry(entity).State = EntityState.Modified;
       }
       public void Delete(T entity)
       {
       _dbSet.Remove(entity);
       }
}

متد FindAsync) id) را برای جست‌وجوی داده‌ها استفاده کرده‌ایم که کارایی بهتری نسبت به FirstOrDefaultAsync دارد.

عملیات حذف بر اساس entity انجام می‌شود تا از اجرای بی‌رویه Find(id) + Remove جلوگیری شود.

تفکیک Domain Model و Entity Model در پروژه‌های بزرگ‌تر

در پروژه‌های کوچک، معمولاً مدل‌های موجودیت (Entity) همان مدل‌هایی هستند که مستقیماً در EF Core و لایه کسب‌وکار استفاده می‌شوند. اما در سیستم‌های Enterprise، بسیاری از تیم‌ها Domain Model و Entity Model را از هم جدا در نظر می‌گیرند. این کار به دلایل زیر توصیه می‌شود:

جلوگیری از وابستگی مستقیم دامنه به EF: اگر روزی لازم شود ORM یا ساختار پایگاه داده را عوض کنید، منطق کسب‌وکار کمتر تحت‌تأثیر قرار می‌گیرد.
امکان توسعهٔ راحت‌تر دامنه: قوانین کسب‌وکار (Business Rules) و رفتارهای مرتبط با دامنه در کلاس‌های Domain تعریف می‌شوند؛ در حالی که Entityها صرفاً برای ذخیره و بازیابی داده هستند.
مپینگ (Mapping) بین Domain و Entity: این جداسازی معمولاً با مپینگ دستی یا ابزارهایی مانند AutoMapper انجام می‌گیرد.

به‌این‌ترتیب، Repository Layer ممکن است فقط با Entity Model درگیر باشد؛ اما در لایهٔ Service یا Application، مدل‌های دامنه برای پردازش منطق کسب‌وکار استفاده شوند.

پیاده‌سازی Unit of Work برای مدیریت تراکنش‌ها

Unit of Work یک لایه مدیریت‌کننده تراکنش‌های مرتبط با رپوزیتوری‌هاست و تضمین می‌کند که چندین عملیات داده‌ای در یک تراکنش اجرا شوند.

public interface IUnitOfWork : IDisposable
{
       IRepository<User> Users { get; }
       IRepository<Order> Orders { get; }
       Task<int> CompleteAsync();
}
public class UnitOfWork : IUnitOfWork
{
       private readonly ApplicationDbContext _context;
       public IRepository<User> Users { get; }
       public IRepository<Order> Orders { get; }
       public UnitOfWork(ApplicationDbContext context)
       {
       _context = context;
       Users = new Repository<User>(context);
       Orders = new Repository<Order>(context);
       }
       public async Task<int> CompleteAsync()
       {
       return await _context.SaveChangesAsync();
       }
       public void Dispose()
       {
       _context.Dispose();
       }
}

مدیریت چندین Repository در یک تراکنش واحد برای جلوگیری از مشکلات Inconsistent State در پایگاه داده

استفاده از CompleteAsync به‌عنوان نقطه نهایی برای ثبت تغییرات در پایگاه داده

استفاده از Repository Pattern در لایه سرویس

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

public class UserService
{
       private readonly IUnitOfWork _unitOfWork;
       public UserService(IUnitOfWork unitOfWork)
       {
       _unitOfWork = unitOfWork;
       }
       public async Task<User> GetUserByIdAsync(int id)
       {
       return await _unitOfWork.Users.GetByIdAsync(id);
       }
       public async Task AddUserAsync(User user)
       {
       await _unitOfWork.Users.AddAsync(user);
       await _unitOfWork.CompleteAsync();
       }
}

نمونه تست واحد (Unit Testing) با استفاده از الگوی Repository

یکی از دلایل اصلی استفاده از Repository Pattern، تست‌پذیری بالاتر است. با وجود یک واسط (Interface) برای رپوزیتوری، می‌توانید در تست‌های واحد، دیتابیس واقعی را کنار بگذارید و Mock یا یک دیتابیس InMemory استفاده کنید.

مثال ساده با Moq:

using Moq;
using Xunit;
public class UserServiceTests
{
    [Fact]
    public async Task GetUserByIdAsync_ReturnsUser()
    {
        // Arrange
        var mockRepo = new Mock<IRepository<User>>();
        mockRepo.Setup(r => r.GetByIdAsync(1))
        .ReturnsAsync(new User { Id = 1, Name = "TestUser" });
        var mockUow = new Mock<IUnitOfWork>();
        mockUow.Setup(u => u.Users).Returns(mockRepo.Object);
        var service = new UserService(mockUow.Object);
        // Act
        var user = await service.GetUserByIdAsync(1);
        // Assert
        Assert.NotNull(user);
        Assert.Equal("TestUser", user.Name);
    }
}

در این مثال:

با استفاده از کتابخانهٔ Moq، رپوزیتوری User را شبیه‌سازی (Mock) کرده‌ایم.
بدون هیچ اتصال واقعی به دیتابیس، GetByIdAsync را تست می‌کنیم.
همچنین می‌توان از InMemory Database در EF Core استفاده کرد تا تست‌ها نیازمند کانفیگ دیتابیس نباشند.

چرا این معماری برای داشبوردها ایده‌آل ست؟

اگر بخواهیم مزایای استفاده از روش الگوی رپوزیتوری را بیان کنیم، موارد زیر در صدر هستند:

افزایش کارایی: حذف وابستگی‌های سخت و استفاده از Asynchronous Processing برای کاهش CPU-bound operations
کاهش سربار پایگاه داده: استفاده از Lazy Loading و Caching برای کاهش تعداد درخواست‌های پایگاه داده
مدیریت بهینه تراکنش‌ها: Unit of Work مانع از ایجاد داده‌های ناسازگار در پایگاه داده می‌شود.

بهینه‌سازی Lazy Loading و Caching در Repository Pattern

Lazy Loading و Caching دو تکنیک رایج برای بهینه‌سازی دسترسی به داده‌ها هستند. با این حال، Lazy Loading همیشه بهترین گزینه نیست زیرا ممکن است باعث N+1 Problem شود.

Lazy Loading در EF Core

EF Core از Lazy Loading پشتیبانی می‌کند، اما باید با دقت از آن استفاده کرد.

public class Blog
{
    public int Id { get; set; }
    public string Title { get; set; 
    public virtual ICollection<Post> Posts { get; set; }
}

نکته مهم: در صورت دسترسی پراکنده به داده‌ها، Lazy Loading ممکن است منجر به کوئری‌های اضافی شود. در چنین شرایطی، Eager Loading) Include) یا Explicit Loading ممکن است گزینه بهتری باشد.

hing در Repository Pattern

کشینگ می‌تواند در دو سطح انجام شود:

کشینگ در سطح اپلیکیشن (Memory Cache / Redis)
کشینگ در سطح دیتابیس (Indexed Views, Materialized Views)

مثال کشینگ در حافظه:

public async Task<IEnumerable<User>> GetAllUsersCachedAsync()
{
    return await _cache.GetOrCreateAsync("UsersCache", async entry =>
    {
        entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);
        return await _repository.GetAllAsync();
    });
}

مقایسه Repository Pattern با سایر رویکردهای طراحی دسترسی به داده در #C

در معماری‌های نرم افزاری #C، روش‌های مختلفی برای درک بهتر داده‌ها وجود دارد که هر کدام مزایا و معایب خاص خود را دارند. در اینجا Repository Pattern را با سه رویکرد رایج مقایسه می‌کنیم:

دسترسی مستقیم به Entity Framework) EF Core)

مزایا: پیاده‌سازی ساده، عملکرد بالا برای عملیات CRUD ساده
معایب: ایجاد وابستگی سخت (Tightly Coupled Code) بین لایه کسب‌وکار و ORM، کاهش انعطاف‌پذیری در تغییر پایگاه داده

Stored Procedures

مزایا: بهینه‌سازی اجرای کوئری‌ها در سطح دیتابیس، مناسب برای پردازش‌های پیچیده
معایب: کاهش Portability، دشواری در نگهداری و تست واحد

Dapper) Micro ORM)

مزایا: عملکرد بسیار سریع، انعطاف‌پذیری بالا در مدیریت کوئری‌های SQL
معایب: نیاز به نوشتن کوئری‌های SQL به‌صورت دستی، کاهش ماژولار بودن کد

الگوی Repository تعادلی بین توسعه آسان، انعطاف‌پذیری و تست‌پذیری ایجاد می‌کند و یک لایه فرضی و ذهنی برای مدیریت داده‌ها ارائه می‌دهد که در پروژه‌های مقیاس‌پذیر و سازمانی بسیار کاربردی است.

آیا EF Core خود یک Repository نیست؟

در جامعه دات‌نت، همیشه این سوال مطرح است که «آیا EF Core خود به‌تنهایی یک Repository محسوب نمی‌شود؟» در واقع، EF Core بسیاری از قابلیت‌های یک Repository را فراهم می‌کند، اما استفاده از Repository Pattern همچنان مزایایی دارد:

کاهش وابستگی کسب‌وکار به EF Core و امکان تغییر ORM در آینده. کنترل بیشتر بر روی ساختار کوئری‌ها و استفاده از Caching، Lazy Loading و بهینه‌سازی‌ها. ایجاد لایه‌ای استاندارد برای کار با داده‌ها در تیم‌های بزرگ و سازمانی.

در نهایت، اگر پروژه‌ای کوچک و ساده باشد، استفاده از Repository Pattern ممکن است غیرضروری باشد، اما در پروژه‌های Enterprise این الگو همچنان مزیت‌های قابل توجهی دارد.

انتخاب یک رویکرد بهینه برای مدیریت داده‌ها

Repository Pattern با ارائه یک لایه انتزاعی پایدار و قابل تست، روشی صحیح و قدرتمند برای مدیریت داده‌ها در برنامه‌های سی شارپ به حساب می‌آید. این الگو در مقایسه با روش‌های سنتی مانند دسترسی مستقیم به EF Core، استفاده از Stored Procedures یا Dapper، تعادل مطلوب‌تری بین انعطاف‌پذیری، قابلیت نگهداری و مقیاس‌پذیری ایجاد می‌کند. پیاده‌سازی اصولی این الگو به بهبود کارایی، درک بهتر داده‌ها، خوانایی کد و کاهش وابستگی‌های ماژولار در معماری نرم ‌افزار منجر می‌شود. در نهایت، انتخاب بهترین روش به نیازهای پروژه، حجم داده‌ها و پیچیدگی سیستم بستگی دارد.

مدیریت Concurrency در Repository Pattern

هم‌زمانی (Concurrency) یکی از چالش‌های پروژه‌های Enterprise است. Unit of Work به‌تنهایی نمی‌تواند مشکلات هم‌زمانی را حل کند. در EF Core می‌توان از Optimistic Concurrency برای مدیریت هم‌زمانی استفاده کرد:

public class Order
{
    public int Id { get; set; }
    public string Status { get; set; }
    [Timestamp]
    public byte[] RowVersion { get; set; }
}

نکته مهم: در صورت تغییر یک رکورد توسط کاربر دیگر، EF Core خطای Concurrency Exception را برمی‌گرداند که می‌توان آن را مدیریت کرد.

سخن پایانی

الگوی repository pattern در #C شرح یکی از بهترین روش‌ها برای مدیریت داده‌ها در برنامه‌های سی شارپ محسوب می‌شود، زیرا باعث کاهش وابستگی‌های سخت، افزایش تست‌پذیری و بهینه‌سازی پردازش داده‌ها می‌شود. این الگو در کنار CQRS و Unit of Work می‌تواند کارایی و مقیاس‌پذیری بالایی برای نرم‌افزارهای داده‌محور فراهم کند.

استفاده از Repository Pattern مزایایی مانند تفکیک لایه کسب‌وکار از پایگاه داده، بهینه‌سازی تراکنش‌ها، کاهش بار روی پایگاه داده و افزایش انعطاف‌پذیری را به همراه دارد. اگرچه روش‌های دیگر مانند Stored Procedures، Dapper و استفاده مستقیم از EF Core نیز کاربردی هستند، اما Repository Pattern یک تعادل منطقی بین توسعه آسان، تست‌پذیری و انعطاف‌پذیری ایجاد می‌کند.

نظر شما در مورد این الگو چیست؟ آیا تجربه‌ای از پیاده‌سازی Repository Pattern در پروژه‌های خود داشته‌اید؟ با ما در نیک آموز در بخش نظرات این مقاله تجربه خود را به اشتراک بذارید. همچنین این مقاله را با همکاران و دوستان خود که در حوزه سی شارپ و معماری نرم‌افزار فعالیت دارند به اشتراک بگذارید تا نظرات بیشتری درباره این روش دریافت کنیم!

سوالات متداول الگوی repository pattern در سی شارپ

چرا باید از Repository Pattern در #C استفاده کنیم؟

Repository Pattern باعث جدا شدن منطق کسب‌وکار از لایه داده، بهبود تست‌پذیری، افزایش خوانایی کد و کاهش وابستگی‌های مستقیم به ORMهایی مانند Entity Framework می‌شود. همچنین تغییر پایگاه داده بدون تغییر در لایه کسب‌وکار را آسان‌تر می‌کند.

چه تفاوتی بین Repository Pattern و استفاده مستقیم از Entity Framework وجود دارد؟

در روش دسترسی مستقیم به Entity Framework، لایه کسب‌وکار به‌طور مستقیم با پایگاه داده در ارتباط است، که وابستگی سخت (Tightly Coupled Code) ایجاد می‌کند. اما Repository Pattern یک لایه انتزاعی (Abstraction Layer) بین این دو ایجاد می‌کند که باعث افزایش انعطاف‌پذیری و تست‌پذیری می‌شود.

Repository Pattern بهتر است یا Dapper؟

اگر سرعت بالا و اجرای مستقیم کوئری‌های SQL برایتان مهم است، Dapper انتخاب بهتری خواهد بود. اما اگر به یک معماری سازمانی، مقیاس‌پذیری و تست‌پذیری بهتر نیاز دارید، Repository Pattern در کنار Unit of Work گزینه‌ی مناسب‌تری خواهد بود.

چگونه می‌توان Repository Pattern را در پروژه‌های بزرگ بهینه‌تر کرد؟

ترکیب Repository Pattern با CQRS (جداسازی خواندن و نوشتن) و Unit of Work به بهینه‌سازی پردازش داده‌ها، افزایش خوانایی و بهبود مدیریت تراکنش‌ها کمک می‌کند. همچنین استفاده از Lazy Loading و Caching می‌تواند بار روی پایگاه داده را کاهش دهد.

آیا Repository Pattern برای تمامی پروژه‌ها مناسب است؟

این الگو برای پروژه‌های سازمانی، سیستم‌های داده‌محور و نرم‌افزارهای با معماری چندلایه (N-Tier Architecture) بسیار مناسب است. اما در پروژه‌های کوچک با تعامل ساده با پایگاه داده، استفاده از این الگو ممکن است پیچیدگی اضافی ایجاد کند.