Where should I put the complex queries using the Repository Pattern?-CodePudding

I have an application in which I use Entity Framework, and I have a class called BaseRepository<T> with a few basic CRUD methods, such as (Get, GetAll, Update, Delete, Insert), and from this class I generate my specific repositories, such like BaseRepository <Products>, BaseRepository<People>, BaseRepository<Countries> and many more.

The problem is that, when I have a complex logic in the service, that involves making joins of several tables and that does not return an entity, but an object that is handled in the service (it is neither a DB entity nor a DTO), I find that repositories don't help me much with just basic CRUD operations.

Where should I put this query complex? in which of the repositories should it be? How do I join these repositories? The problem is that I see that the repositories handle a single entity, what should I do in this case? I've been doing some research and read that returning IQueryable<T> is bad practice, so I rule out that possibility of sending IQueryable<T> of the tables I'm going to join the service and do it there.

I've researched and found no clear answer. I would like to know how and where these complex queries are organized, since I also want to respect the responsibility of each repository with its respective entity.

CodePudding user response：

I would like to know how and where these complex queries are organized, since I also want to respect the responsibility of each repository with its respective entity.

The complex queries are the responsibility of the code that is requesting the data, not the responsibility of the repository. The single responsibility of the repository is to provide access to the data, not to provide every possible request shape that may be needed in any use case. You really want to write methods in your repositories like:

customerRepo.GetCustomerWithLastTenOrdersAndSupportCasesAsDTO()

customerRepo.GetCustomerForCustomerSupportHomePage()

Of course not. So your repository provides a property of type IQueryable<T> or DbSet<T> which can be used as a starting point for consumers to add whatever queries they need.

I've been doing some research and read that returning IQueryable is bad practice

Don't beleive everything you read. There's really not a good alternative to exposing IQueryable<T> from your repository. And once you digest that, there's not much of a reason to have any repository type other than your DbContext subtype.

CodePudding user response：

Its hard to answer without having a code to understand what you want to achieve, hopefully my answer gives you an idea on how you can use abstract classes to override your Queryable Collection. If your requirement is more complex, can you provide more information with example code.

Create your BaseRepository like this -

public abstract class BaseRepository<T>
{
    public IQueryable<T> Collection { get; set; }
    public readonly DbContext _context;

    public BaseRepository(DbContext context)
    {
        _context = context;
        Collection = SetQueryableCollection();
    }

    public virtual IQueryable<T> SetQueryableCollection() => _context.Set<T>();

    // CRUD Operations here for e.g. -
    public virtual async Task<List<T>> Get()
    {
        return await Collection.ToListAsync();
    }
}

Now, the class that inherits this -

public class ProductRepository : BaseRepository<Product>
{
    public ProductRepository(MyContext context) : base(context)
    {
    }

    //now override the method that sets the collection
    public override IQueryable<Product> SetQueryableCollection() => 
        _context.Set<Product>().Include(p => p.Brand).ThenInclude(...);

    // things to keep in mind, the _context is public in the way I've done it. You can change that and directly expose the Collection and set it to your need per entity type.
}

So now your GET method uses the overriden method to set the Collection.