Repository Pattern Over EF: Boon or Burden?

  
    // In Program.cs or your DI setup
services.AddScoped<IReadCategoryRepository, CategoryRepository>();
services.AddScoped<IWriteCategoryRepository, CategoryRepository>();
  

And in your services:

  
    // Admin service - full access
public class AdminCategoryService
{
    private readonly IWriteCategoryRepository _writeRepo;
    private readonly IReadCategoryRepository _readRepo;
    public AdminCategoryService(IWriteCategoryRepository writeRepo,                   
                               IReadCategoryRepository readRepo)
    {
        _writeRepo = writeRepo;
        _readRepo = readRepo;

    }

    public async Task AddCategoryAsync(Category category)
        => await _writeRepo.AddAsync(category);
}

// User service - read-only access
public class UserCategoryService
{
    private readonly IReadCategoryRepository _readRepo;

    public UserCategoryService(IReadCategoryRepository readRepo)
    {
        _readRepo = readRepo;
    }

    public async Task<List<Category>> GetCategoriesAsync()
        => await _readRepo.GetListAsync();
}
  

This way:

• 🧱 Each service gets only what it needs

• 🔒 Write operations are limited to authorized areas

• 🧼 Your code stays clean, testable, and easy to reason about

Generic repositories are great for reusability, but splitting them into read and write repositories gives you clarity, security, and maintainability — the marks of a mature system. 💪

🎯 Making Queries Smarter — Introducing the Specification Pattern

Alright, so far you’ve done an awesome job 👏
You’ve learned how to:

• ✅ Use repositories to avoid direct DbContext access

• ✅ Split them into read and write repositories to control access

But now your inner developer voice says again…

Okay, but every time I need to filter or query data differently — I keep adding more methods like GetActiveCategories, GetByName, GetByCreatedDate…
Isn’t this going to explode my repository with too many methods? 🤯

Exactly! That’s where the Specification Pattern comes to the rescue 🚀

💡 What Is the Specification Pattern?

Think of the Specification Pattern as a smart way to build reusable and composable queries .

Instead of writing multiple methods for every query scenario,
you define small, focused classes (called specifications ) that describe what you want — not how to get it.

It’s like giving your repository a set of “query rules” that can be combined and reused anywhere.

Think of specifications like filters on an e-commerce website 🛍️
You don’t hardcode “GetT-shirtsByColor”, “GetT-shirtsBySize”, “GetT-shirtsByBrand”. Instead, you create reusable filters — color , size , brand — and combine them as needed.

🧱 Without Specification — The Problem

Here’s what typically happens without it 👇

  
    public class CategoryRepository : IReadCategoryRepository
{
    public Task<List<Category>> GetActiveCategoriesAsync() 
    { ... }
    public Task<List<Category>> GetCategoriesByNameAsync(string name) 
    { ... }
    public Task<List<Category>> GetByParentIdAsync(Guid parentId) 
    { ... }
}
  

Before long, your repository turns into a method jungle 🌴, hard to maintain, repetitive, and full of slightly different queries.

🪄 With Specification — The Clean Way

With the Specification Pattern , you move query logic out of the repository and into small reusable rules .

Step 1️⃣: Define a Base Specification

  
    public interface ISpecification<T>
{
    Expression<Func<T, bool>>? Criteria { get; }
    Func<IQueryable<T>, IOrderedQueryable<T>>? OrderBy { get; }
}
  

This tells us:

• Criteria — What to filte

• OrderBy — How to sort

Step 2️⃣: Create a Concrete Specification

  
    public class ActiveCategorySpecification : ISpecification<Category>
{
    public Expression<Func<Category, bool>> Criteria 
        => c => c.IsActive == true;
}
  

You can now reuse this specification anywhere you want to get only active categories.

Step 3️⃣: Make the Repository Understand the Specification

Modify your read repository to support specs 👇

  
    public interface IReadRepository<T>
{
    Task<List<T>> GetListAsync(ISpecification<T>? spec = null);
}
  

And in implementation

  
    public async Task<List<T>> GetListAsync(ISpecification<T>? spec = null)
{
    IQueryable<T> query = _context.Set<T>();

    if (spec?.Criteria is not null)
        query = query.Where(spec.Criteria);

    if (spec?.OrderBy is not null)
        query = spec.OrderBy(query);

    return await query.ToListAsync();
}
  

Now your repository can handle any type of query — without changing its own code. 🎉

Step 4️⃣: Using the Specification

  
    var spec = new ActiveCategorySpecification();
var activeCategories = await _readCategoryRepository.GetListAsync(spec);
  

Boom 💥 — clean, reusable, and scalable. No more writing separate methods for every filter or sort.

🧠 As a result of using the specification pattern, you will get the following

• 🔁 Reusable — Define a query once, reuse it everywhere

• 🧩 Composable — Combine multiple specifications if needed

• 💬 Readable — Your query logic becomes self-explanatory

• 🔒 Safe — Keeps repository clean and free from random query overload

Bringing It All Together — Unit of Work + Specification Pattern in Action

🧱 Create a Unit of Work Interface

The Unit of Work acts like a transaction manager — it keeps track of all repositories and ensures all database operations are completed together.

  
    public interface IUnitOfWork : IDisposable
{
    IReadCategoryRepository CategoriesRead { get; }
    IWriteCategoryRepository CategoriesWrite { get; }

    IReadRepository<Product> ProductsRead { get; }
    IWriteRepository<Product> ProductsWrite { get; }

    Task<int> SaveChangesAsync();
}
  

⚙️ Implement the Unit of Work

  
    public class UnitOfWork : IUnitOfWork
{
    private readonly AppDbContext _context;

    public UnitOfWork(AppDbContext context)
    {
        _context = context;
        CategoriesRead = new CategoryRepository(_context);
        CategoriesWrite = new CategoryRepository(_context);
        ProductsRead = new ProductRepository(_context);
        ProductsWrite = new ProductRepository(_context);
    }

    public IReadCategoryRepository CategoriesRead { get; }
    public IWriteCategoryRepository CategoriesWrite { get; }

    public IReadRepository<Product> ProductsRead { get; }
    public IWriteRepository<Product> ProductsWrite { get; }

    public async Task<int> SaveChangesAsync() => 
          await _context.SaveChangesAsync();

    public void Dispose() => _context.Dispose();
}
  

✅ All repositories share the same DbContext ,

So any changes made through them are tracked together and committed as a single transaction.

🧩 Sample Repository Implementation with Specification Support

Let’s take CategoryRepository that supports both read and write operations using the Specification Pattern :

  
    public class CategoryRepository : IReadCategoryRepository, IWriteCategoryRepository
{
    private readonly AppDbContext _context;

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

    // READ
    public async Task<Category?> GetByIdAsync(Guid id)
        => await _context.Categories.FindAsync(id);

    public async Task<List<Category>> GetListAsync(ISpecification<Category>? spec = null)
    {
        IQueryable<Category> query = _context.Categories.AsQueryable();

        if (spec?.Criteria is not null)
            query = query.Where(spec.Criteria);

        if (spec?.OrderBy is not null)
            query = spec.OrderBy(query);

        return await query.ToListAsync();
    }

    // WRITE
    public async Task AddAsync(Category category)
        => await _context.Categories.AddAsync(category);

    public Task UpdateAsync(Category category)
    {
        _context.Categories.Update(category);
        return Task.CompletedTask;
    }

    public Task DeleteAsync(Category category)
    {
        _context.Categories.Remove(category);
        return Task.CompletedTask;
    }
}
  

🧠 Example Specification

  
    public class ActiveCategorySpecification : ISpecification<Category>
{
    public Expression<Func<Category, bool>> Criteria => c => c.IsActive;
    public Func<IQueryable<Category>, IOrderedQueryable<Category>>? OrderBy => q => q.OrderBy(c => c.Name);
}
  

💼 Use Everything Together in a Service

Now, let’s see how the Unit of Work and Specification Pattern play together beautifully:

  
    public class CategoryService
{
    private readonly IUnitOfWork _unitOfWork;

    public CategoryService(IUnitOfWork unitOfWork)
    {
        _unitOfWork = unitOfWork;
    }

    // 🧠 Read with specification
    public async Task<List<Category>> GetActiveCategoriesAsync()
    {
        var spec = new ActiveCategorySpecification();
        return await _unitOfWork.CategoriesRead.GetListAsync(spec);
    }

    // 🏗️ Write and commit in one transaction
    public async Task AddCategoryAsync(Category category)
    {
        await _unitOfWork.CategoriesWrite.AddAsync(category);
        await _unitOfWork.SaveChangesAsync(); // Commits all changes together
    }
}
  

Now if you also update products within the same unit of work, they’ll be saved together in one transaction 👇

  
    public async Task AddCategoryAndUpdateProductAsync(Category category, Product product)
{
    await _unitOfWork.CategoriesWrite.AddAsync(category);
    _unitOfWork.ProductsWrite.UpdateAsync(product);

    // Both operations are tracked under same DbContext
    await _unitOfWork.SaveChangesAsync(); // ✅ Commit once
}
  

If any part fails — everything rolls back, keeping your data consistent 💾

⚡ Register Everything in the Program.cs

  
    builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();
builder.Services.AddScoped<IReadCategoryRepository, CategoryRepository>();
builder.Services.AddScoped<IWriteCategoryRepository, CategoryRepository>();
  

Conclusion

While Entity Framework gives you powerful data access out of the box, relying on it directly can easily blur boundaries and couple your domain logic with persistence details.

That’s where the Repository Pattern truly shines ✨ — it acts as a clean layer between your business logic and database, making your code more organized, testable, and future-proof.

So yes, EF can handle the queries — but the Repository Pattern helps you handle your architecture. Use it to keep your application maintainable, flexible, and ready to grow. 🚀

💬 Found This Helpful?

If this article helped you understand the Repository Pattern better, please share it with your friends and teammates — it might help them too! 🙌

And if you have any suggestions or thoughts to make it even better, drop them in the comments — I’d love to hear from you. 💡