Repository و Unit of Work در Infrastructure Layer: الگوها، مزایا و خطاهای رایج

Repository Pattern در لایهٔ Infrastructure: در برنامه‌های مقیاس پایین‌تر، اغلب منطق دسترسی به دیتابیس مستقیماً داخل سرویس‌ها یا کنترلرها نوشته می‌شود. مثلاً:

var products = await _dbContext.Products.ToListAsync();

این روش در ابتدا ساده و قابل‌فهم است، اما وقتی سیستم رشد می‌کند، به چند مشکل جدی برمی‌خوریم:

• هر بخش از سیستم خودش به شکل متفاوتی با دیتابیس کار می‌کند.
• تست‌پذیری بسیار سخت می‌شود (به‌ویژه بدون دیتابیس واقعی).
• اگر روزی ORM یا ساختار دیتابیس تغییر کند، باید ده‌ها کلاس را بازنویسی کنیم.

این‌ها همان «مشکل اصلی در دسترسی به داده‌ها» هستند که در پروژه‌های واقعی خودشان را نشان می‌دهند و ضرورت استفاده از الگوهایی مثل Repository و Unit of Work را پررنگ می‌کنند.

مثالی از انباردار شرکت برای  Repository Pattern

فرض کنید در یک شرکت بزرگ، هر دپارتمان مستقیم به انبار می‌رفت تا خودش کالاها را بردارد، اضافه کند یا حذف کند!
نتیجه چنین فرایندی بهم ریختگی بوجود میاورد: بعضی اقلام گم می‌شدند، بعضی دوبار ثبت می‌شدند، و به سختی موجودی واقعی مشخص می‌باشد؛ برای حل این مشکل، شرکت تصمیم می‌گیرد یک انباردار مرکزی استخدام کند. همه‌ی درخواست‌ها باید از طریق او انجام شود: او می‌داند چطور کالاها را بگیرد، ثبت کند، یا حذف کند، بدون اینکه بخش‌های دیگر بدانند داخل انبار دقیقاً چه خبر است. در معماری نرم‌افزار، Repository همان انباردار داده‌ها است؛ دسترسی به پایگاه‌داده را متمرکز می‌کند و لایه‌های بالاتر (مثل Domain یا Application) را از جزییات ORM جدا می‌سازد.

مفهوم فنی Repository چیست؟

Repository یک الگوی طراحی (Design Pattern) است که:

• وظیفه دارد بین دامنه (Domain) و منبع داده (Data Source) نقش واسطه ایفا کند.
• منطق CRUD و Queryها را در خودش نگه دارد.
• باعث می‌شود لایه‌های دیگر تنها با انتزاع (abstraction)کار کنند نه با EF Core ،SQL یا MongoDB.
  

به بیان ساده:

Repository = لایه‌ای که داده‌ها را مدیریت می‌کند، نه به این خاطر که SQL بلد است، بلکه چون می‌داند داده‌های دامنه چیست و چطور باید با آن‌ها کار کرد.

مشاهده کامل ترین وجامع ترین آموزش برنامه نویسی

ساختار کلی در لایهٔ Infrastructure

در معماری تمیز (Clean Architecture) معمولاً ساختار به این شکل است:

Application/

    └── Interfaces/

        └── IProductRepository.cs

Domain/

    └── Entities/

        └── Product.cs

Infrastructure/

    └── Persistence/

        ├── AppDbContext.cs

        └── Repositories/

            ├── BaseRepository.cs

            └── ProductRepository.cs

مراحل پیاده‌سازی لایهٔ Infrastructure

۱. تعریف یک اینترفیس عمومی (Base Contract)

public interface IRepository<T> where T : class

{

    Task<T?> GetByIdAsync(Guid id);

    Task<IEnumerable<T>> GetAllAsync();

    Task AddAsync(T entity);

    void Update(T entity);

    void Remove(T entity);

}

این همان قرارداد پایه بین لایهٔ Application و Infrastructure است.
لایه‌های بالاتر فقط می‌دانند که چنین متدهایی وجود دارد؛ نه اینکه از EF Core استفاده می‌شود یا از Dapper.گاهی وقت ها بسته به موارد پروژه مدل های ریپازیتوری را می توان بهمراه فیلتر کردن هایی به سمت دیتابیس به صورت جنریک تعریف کرد.

۲. ساخت Base Repository در Infrastructure

public class BaseRepository<T> : IRepository<T> where T : class
{
    protected readonly AppDbContext _context;

    public BaseRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task<T?> GetByIdAsync(Guid id) => await _context.Set<T>().FindAsync(id);

    public async Task<IEnumerable<T>> GetAllAsync() => await _context.Set<T>().ToListAsync();

    public async Task AddAsync(T entity) => await _context.Set<T>().AddAsync(entity);

    public void Update(T entity) => _context.Set<T>().Update(entity);

    public void Remove(T entity) => _context.Set<T>().Remove(entity);

}

در اینجا، BaseRepository نقش همان انباردار اصلی شرکت را دارد؛او می‌داند چطور عملیات پایه را انجام دهد، اما جزئیات محصول خاصی را نمی‌داند.

۳. ارث‌بری برای ریپازیتوری‌های خاص دامنه

public interface IProductRepository : IRepository<Product>
{
    Task<IEnumerable<Product>> GetAvailableProductsAsync();
}
public class ProductRepository : BaseRepository<Product>, IProductRepository
{
    public ProductRepository(AppDbContext context) : base(context) { }

    public async Task<IEnumerable<Product>> GetAvailableProductsAsync()
    {
        return await _context.Products
           .Where(p => p.IsAvailable)
            .ToListAsync();
    }
}

اینجا اصل شی‌گرایی وارد عمل می‌شود:
با ارث‌بری (Inheritance) قابلیت پایه را می‌گیریم و متدهای خاص محصول را به آن اضافه می‌کنیم.اگر فردا CustomerRepository بخواهیم، کافی‌ست از همان BaseRepository<Customer> ارث ببریم.

خطاهای رایج در پیاده‌سازی Repository

۱. ایجاد Repository بدون هدف

• وقتی فقط یک CRUD ساده داریم، استفاده از Repository اضافی است.
• در EF Core خود DbContext نقش Repository را بازی می‌کند.
  
• در پروژه‌های کوچک، این الگو ممکن است فقط کد اضافه تولید کند.

۲. بازگرداندن IQueryable

• بازگرداندن IQueryable<T> از Repository باعث نشت جزئیات ORM می‌شود.
• در عوض، خروجی نهایی (IEnumerable, DTO) را برگردانید.

۳. نوشتن منطق دامنه در Repository

• Repository باید فقط داده را بخواند یا بنویسد.
  
• قوانین تجاری (Business Logic) نباید در این لایه قرار گیرد.

۴. استفاده نادرست از Generic Repository

• اگر همه‌چیز را در BaseRepository جمع کنید، flexibility از بین می‌رود.
  
• گاهی بهتر است برای aggregateهای خاص Repository مستقل بسازید.

Repository، پلی میان دامنه و داده

Repository Pattern یکی از مهم‌ترین اجزای لایهٔ Infrastructure در معماری تمیز است.
با استفاده از آن:

• داده‌ها از منطق تجاری جدا می‌شوند؛
  
• تست‌پذیری و نگه‌داری سیستم بهبود پیدا می‌کند؛
  
• و تیم توسعه می‌تواند روی «چیستی داده» تمرکز کند نه «چگونگی ذخیره‌سازی آن».
  

بخش بعدی به Unit of Work Pattern اختصاص دارد؛ الگویی که همهٔ Repositoryها را در یک تراکنش منسجم کنار هم نگه می‌دارد، درست مثل مدیری که چند انبار را هم‌زمان کنترل می‌کند تا تمام تغییرات یا به‌صورت یک‌جا ثبت شوند یا هیچ‌کدام اعمال نشوند.

Unit of Work Pattern در لایهٔ Infrastructure؛ هماهنگ‌کنندهٔ عملیات داده‌ای در یک تراکنش منسجم

وقتی چند Repository با هم کار می‌کنند

فرض کنید در یک فروشگاه اینترنتی‌، کاربر سفارشی ثبت می‌کند.در این فرآیند باید هم‌زمان چند موجودیت ذخیره شوند:

• Order در جدول سفارش‌ها
  
• OrderItem در جدول جزئیات
  
• و موجودی (Stock) در جدول محصولات کم شود
  

هرکدام از این‌ها معمولاً در Repository خودش انجام می‌شود.سوال مهمی پیش می‌آید:

اگر وسط عملیات، یکی از Repositoryها خطا بدهد، چه می‌شود؟ آیا بخشی از داده ذخیره می‌شود و بخشی نه؟ این‌جاست که Unit of Work Pattern نقش حیاتی پیدا می‌کند.

شخصی برای هماهنگ‌کنندهٔ انبارها

در بخش قبل گفتیم Repository مثل انباردار است.حالا فرض کنید چند انبار وجود دارد، یکی برای محصولات، یکی برای سفارش‌ها، یکی برای مشتری‌ها.

اگر شرکت بخواهد همهٔ این انبارها با هم یک سفارش را ثبت کنند، باید مدیری مرکزی داشته باشد که بر همه نظارت کند:

• اگر همه چیز موفق بود، تأیید نهایی را صادر کند.
  
• اگر جایی خطا رخ داد، همهٔ تغییرات را لغو کند (Rollback).
  

در معماری نرم‌افزار، این شخص همان Unit of Work است.

مفهوم فنی Unit of Work چیست؟

به زبان ساده:

Unit of Work یک الگوست که مجموعه‌ای از عملیات پایگاه‌داده را به‌عنوان یک «عملیات مرکزی» مدیریت می‌کند، یعنی همه یا هیچ‌کدام انجام شوند.در EF Core، خود DbContext ذاتاً نقش Unit of Work را دارد، چون تمام تغییرات را تا زمانی که SaveChanges() صدا زده نشود، در حافظه نگه می‌دارد. اما وقتی چند Repository جدا داریم، به یک لایهٔ هماهنگ‌کننده نیاز داریم تا همهٔ آن‌ها از یک context مشترک استفاده کنند.

ساختار در Clean Architecture

Application/

    └── Interfaces/

        ├── IUnitOfWork.cs

        └── IProductRepository.cs

Infrastructure/

    └── Persistence/

        ├── AppDbContext.cs

        └── UnitOfWork.cs

پیاده‌سازی گام‌به‌گام

۱. تعریف قرارداد Unit of Work

public interface IUnitOfWork : IDisposable

{

    IProductRepository Products { get; }

    IOrderRepository Orders { get; }

    Task<int> SaveChangesAsync();

}

در این اینترفیس:

• هر Repository به‌صورت property تعریف شده.
  
• متد SaveChangesAsync() نقش commit تراکنش را دارد.
  
• Dispose() هم برای آزادسازی منابع است.
  

۲. پیاده‌سازی UnitOfWork در Infrastructure

public class UnitOfWork : IUnitOfWork
{
    private readonly AppDbContext _context;
    public IProductRepository Products { get; }
    public IOrderRepository Orders { get; }
    public UnitOfWork(AppDbContext context,
                      IProductRepository productRepository,

                      IOrderRepository orderRepository)
    {
        _context = context;

        Products = productRepository;

        Orders = orderRepository;
    }

    public async Task<int> SaveChangesAsync()
    {
        return await _context.SaveChangesAsync();
    }

    public void Dispose()
    {
        _context.Dispose();
    }
}

اینجا تمام Repositoryها از یک DbContext مشترک استفاده می‌کنند. بنابراین هر تغییری تا زمان SaveChangesAsync() فقط در حافظه باقی می‌ماند. اگر یکی از مراحل خطا دهد، DbContext rollback می‌کند و دیتابیس تمیز می‌ماند.

۳. استفاده از UnitOfWork در Application Layer

public class OrderService
{
    private readonly IUnitOfWork _unitOfWork;
    public OrderService(IUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }
    public async Task PlaceOrderAsync(Order order)
    {
        await _unitOfWork.Orders.AddAsync(order);
        foreach (var item in order.Items)
        {
            var product = await _unitOfWork.Products.GetByIdAsync(item.ProductId);
            product.Stock -= item.Quantity;
            _unitOfWork.Products.Update(product);
        }

        await _unitOfWork.SaveChangesAsync(); // همه با هم ذخیره می‌شوند
    }
}

در اینجا تمام تغییرات روی چند Repository انجام شده‌اند، اما فقط یک بار ذخیره (commit) صورت گرفته؛ دقیقاً مثل تراکنش بانکی.

خطاهای رایج در پیاده‌سازی Unit of Work

۱. ایجاد UnitOfWork بدون Repository واقعی
اگر پروژه فقط یک Repository دارد، UnitOfWork بی‌دلیل پیچیدگی اضافه می‌آورد.

۲. ایجاد DbContext جدا در هر Repository
بزرگ‌ترین اشتباه: اگر هر Repository یک DbContext جدا داشته باشد، دیگر هیچ هماهنگی وجود ندارد.همه باید از یک context اشتراکی استفاده کنند.

۳. فراخوانی SaveChanges در خود Repository
Repository نباید خودش داده را commit کند. این وظیفهٔ UnitOfWork است که کنترل کامل تراکنش را در دست داشته باشد.

۴. وابستگی معکوس نادرست (Bad DI setup)
در DI باید UnitOfWork در سطح Scoped ثبت شود، نه Transient یا Singleton، تا DbContext در طول یک درخواست HTTP مشترک باقی بماند.

تا اینجا یاد گرفتیم که در معماری تمیز:

• Repository داده‌ها را انتزاع می‌کند.
• UnitOfWork این داده‌ها را در قالب یک تراکنش مرکزی کنترل می‌کند.

با این دو الگو:

مستقل بودن (اصلی از اصول SOLID) لایه‌ها حفظ می‌شود، تست‌پذیری افزایش می‌یابد، و سیستم در برابر خطاهای داده‌ای بهینه تر عمل می کند.

منسجم‌ترین آموزش برنامه‌نویسی رایگان، با محتوای کاربردی و مسیر یادگیری واضح.

طراحی Repository و Unit of Work در پروژه‌های واقعی

رویکردهای معماری، مزایا و خطاهای رایج در عمل

۱. سناریوی واقعی: سیستم فروش (Sales System)

پروژه ای رو داریم با اطلاعات زیر:

• مدیریت محصولات (Products)
  
• ثبت سفارش (Orders)
  
• مدیریت مشتریان (Customers)
  
• و گزارش‌گیری فروش (Reports)
  

هر بخش دیتای مخصوص خودش را دارد، اما در بعضی عملیات (مثل ثبت سفارش) باید چند Repository با هم هماهنگ شوند.

طراحی منطقی در Clean Architecture به این شکل است:

Domain/

  └── Entities/

      ├── Product.cs

      ├── Order.cs

      └── Customer.cs

Application/

  └── Interfaces/

      ├── IProductRepository.cs

      ├── IOrderRepository.cs

      ├── ICustomerRepository.cs

      └── IUnitOfWork.cs


Infrastructure/

  └── Persistence/

      ├── AppDbContext.cs

      ├── Repositories/

      │   ├── ProductRepository.cs

      │   ├── OrderRepository.cs

      │   └── CustomerRepository.cs

      └── UnitOfWork.cs

در این ساختار:

• هر Repository مسئول نوع خاصی از داده است.
  
• UnitOfWork بین آن‌ها یکپارچگی ایجاد می‌کند.
  
• Application Layer تنها با IUnitOfWork کار می‌کند، نه EFCore.
  

۲. نمونهٔ واقعی از جریان داده

در متد PlaceOrderAsync، داده‌های زیر باید ذخیره شوند:

public async Task PlaceOrderAsync(Order order)
{
    await _unitOfWork.Orders.AddAsync(order);
    foreach (var item in order.Items)
    {
        var product = await _unitOfWork.Products.GetByIdAsync(item.ProductId);
        product.Stock -= item.Quantity;
        _unitOfWork.Products.Update(product);
    }
    await _unitOfWork.SaveChangesAsync();

}

همه چیز واضح است:

• Repositoryها فقط داده را می‌خوانند و تغییر می‌دهند.
  
• UnitOfWork تضمین می‌کند که تمام تغییرات در یک تراکنش مرکزی ثبت شوند.
  

۳. مزایای به‌کارگیری Repository و Unit of Work در مقیاس سازمانی

استفاده از دو الگوی Repository و Unit of Work در معماری نرم‌افزار، به‌ویژه در پروژه‌های متوسط تا بزرگ، منجر به ایجاد چند مزیت بنیادین در طراحی و نگهداری سیستم می‌شود.نخست، این ساختار موجب پایداری و انسجام داده‌ها (Data Consistency) در عملیات چندمرحله‌ای می‌گردد. تمام تغییرات داده در قالب یک تراکنش مرکزی انجام می‌شود و در صورت بروز خطا، تمامی تغییرات به‌صورت خودکار بازگردانده می‌شوند (Rollback). این ویژگی از ثبت داده‌های ناقص یا متناقض جلوگیری می‌کند.

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

سوم، این الگوها موجب انعطاف‌پذیری در لایه داده (Data Access Flexibility) می‌شوند. در صورت نیاز به جایگزینی ORM (به‌عنوان نمونه، مهاجرت از Entity Framework Core به Dapper)، تنها لایهٔ زیرساخت تغییر می‌کند و سایر لایه‌ها از این تغییر بی‌نیاز می‌مانند.

چهارم، با اعمال این جداسازی، وابستگی میان لایه‌ها (Coupling) به حداقل می‌رسد. لایهٔ کاربردی تنها از Interfaceها استفاده می‌کند و هیچ وابستگی مستقیمی به جزئیات فنی ORM ندارد. در نهایت، این ساختار سبب می‌شود منطق دامنه (Domain Logic) از جزئیات فنی زیرساخت مستقل بماند. در نتیجه، تمرکز اصلی توسعه‌دهندگان بر مدل مفهومی و قوانین تجاری خواهد بود، نه بر نحوهٔ ذخیره یا بازیابی داده.

۴. خطاهای رایج در پیاده‌سازی Repository و Unit of Work

با وجود مزایای متعدد، اشتباه در طراحی یا پیاده‌سازی این دو الگو می‌تواند منجر به بروز مشکلات جدی در پایداری و نگهداری سیستم شود.یکی از خطاهای متداول، ایجاد نمونه‌های مجزا از DbContext در هر Repository است. در این حالت، تراکنش‌ها به‌صورت جداگانه مدیریت می‌شوند و امکان هماهنگی داده‌ها در عملیات چندمرحله‌ای از بین می‌رود.خطای رایج دیگر، فراخوانی متد SaveChanges درون هر Repository است. این کار موجب بی‌اثر شدن نقش Unit of Work می‌شود، زیرا کنترل Commit از سطح مرکزی خارج می‌گردد.همچنین، برخی پیاده‌سازی‌ها اشتباهاً IQueryable را از Repository بازمی‌گردانند، که باعث نشت جزئیات فنی ORM به لایه‌های بالاتر می‌شود و اصل «جداسازی لایه‌ها» را نقض می‌کند.

در مواردی نیز مشاهده می‌شود که برای هر موجودیت (Entity) یک Repository مستقل ایجاد می‌شود، حتی زمانی که هیچ منطق خاصی در آن وجود ندارد. این رویکرد موجب افزایش غیرضروری حجم کد و پیچیدگی پروژه می‌شود.در نهایت، ادغام منطق دامنه (Domain Logic) با منطق داده در Repository یا تنظیم نادرست چرخهٔ عمر UnitOfWork در Dependency Injection از دیگر اشتباهات رایج است که اغلب به بروز خطاهای تراکنشی و ناپایداری داده منجر می‌گردد.

۵. الگوی بهینه در طراحی و پیاده‌سازی

در سازمان‌ها و پروژه‌های Enterprise، الگوی بهینه برای طراحی این دو مفهوم معمولاً شامل چند اصل کلیدی است:

1. استفاده از BaseRepository به‌عنوان مخزن عمومی عملیات CRUD برای تمام موجودیت‌ها.

2. ایجاد Repositoryهای اختصاصی صرفاً برای Aggregate Rootهایی که منطق خاص دامنه در آن‌ها وجود دارد (مانند Order یا Invoice).

3. تعریف UnitOfWork مرکزی که تمام Repositoryها را در بر می‌گیرد و از یک DbContext مشترک استفاده می‌کند.

4. ثبت DbContext در سیستم Dependency Injection با چرخهٔ عمر Scoped، تا تراکنش در سطح درخواست وب حفظ شود.

5. برقراری ارتباط لایه Application صرفاً از طریق Interfaceهای قراردادی (مانند IUnitOfWork) و عدم استفاده مستقیم از Repositoryهای پیاده‌سازی‌شده.

6. در عملیات پیچیده‌تر، استفاده از TransactionScope برای هماهنگی بین چند Context یا سرویس جداگانه.

این ترکیب باعث می‌شود ساختار سیستم از نظر پایداری، مقیاس‌پذیری و نگهداری در وضعیت بهینه قرار گیرد.

۶. چالش‌های عملی در پروژه‌های واقعی

در پروژه‌های بزرگ و سامانه‌های با حجم داده بالا، اجرای صحیح این دو الگو با چالش‌های متعددی همراه است. یکی از چالش‌های رایج، کاهش کارایی در تراکنش‌های سنگین است. در چنین مواردی، متد SaveChanges باید به‌صورت دسته‌ای (Batch) و کنترل‌شده اجرا شود تا از فشار بیش از حد به پایگاه داده جلوگیری گردد. چالش دیگر، مدیریت هم‌زمانی (Concurrency Handling) است. در محیط‌هایی که چند کاربر به‌صورت هم‌زمان داده‌ها را تغییر می‌دهند، استفاده از مکانیزم‌هایی مانند RowVersion در Entity Framework ضروری است.

در معماری‌های مدرن مبتنی بر دامنه (DDD)، UnitOfWork اغلب نقش هماهنگ‌کنندهٔ Domain Eventها را نیز بر عهده دارد؛ به‌طوری‌که Commit موفق تراکنش منجر به انتشار Eventهای دامنه در الگوی Outbox می‌شود. در حوزهٔ تست نیز، ایزولاسیون کامل واحدها اهمیت بالایی دارد. در آزمون‌های مرکزی باید UnitOfWork و Repositoryها به‌صورت Mock پیاده‌سازی شوند تا از وابستگی به پایگاه داده واقعی جلوگیری شود.

۷. ارزیابی موقعیت استفاده از Repository و Unit of Work

کاربرد این دو الگو در تمام پروژه‌ها ضروری نیست. انتخاب آن‌ها باید بر اساس مقیاس، پیچیدگی و نیازهای معماری صورت گیرد.

در پروژه‌های کوچک و ساده که تنها شامل عملیات CRUD پایه هستند، استفاده از Repository و UnitOfWork ممکن است منجر به افزایش بی‌مورد حجم کد شود، زیرا Entity Framework Core خود به‌صورت داخلی این دو الگو را پیاده‌سازی کرده است. در مقابل، در پروژه‌های متوسط تا بزرگ، به‌ویژه در سیستم‌هایی که منطق تجاری گسترده یا وابستگی‌های چندلایه دارند، استفاده از این الگوها کاملاً منطقی و مؤثر است. در معماری‌های مبتنی بر Domain-Driven Design (DDD)، این دو الگو از ارکان اصلی زیرساخت محسوب می‌شوند و پیاده‌سازی آن‌ها الزامی است. در محیط‌های مبتنی بر Microservices نیز می‌توان از نسخه‌های ساده‌تر یا سبک‌تر این الگوها در هر سرویس مستقل بهره گرفت.

سخن پایانی

Repositoryها هرکدام مسئول مدیریت بخشی از داده‌ها هستند، در حالی‌که UnitOfWork به‌عنوان مدیر مرکزی اطمینان حاصل می‌کند که تمام تغییرات در یک تراکنش منسجم و مرکزی ذخیره شوند.

سوالات متداول 

۱.چرا در پروژه‌های بزرگ استفاده از Repository ضروری است؟

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

۲.نقش اصلی Unit of Work در کنار Repository چیست؟

Unit of Work عملیات چند Repository را در یک تراکنش هماهنگ می‌کند تا تمام تغییرات یا یک‌جا ذخیره شوند یا در صورت بروز خطا همه تغییرات بازگردانده شوند. این الگو از ایجاد داده‌های ناقص، ناهماهنگ یا بخشی ذخیره‌ شده جلوگیری می‌کند و تضمین می‌کند همهٔ Repositoryها از یک DbContext مشترک استفاده کنند.

۳.رایج‌ترین خطاها در پیاده‌سازی Repository و Unit of Work کدام‌اند؟

از مهم‌ترین خطاها می‌توان به ایجاد Repository و UnitOfWork بدون هدف، بازگرداندن IQueryable و نشت جزئیات ORM، نوشتن منطق دامنه در Repository، ساخت DbContext جدا در هر Repository، فراخوانی SaveChanges در خود Repository و ثبت نادرست چرخهٔ عمر UnitOfWork در Dependency Injection اشاره کرد. این خطاها موجب ناپایداری تراکنش‌ها و افزایش پیچیدگی پروژه می‌شوند.