使用 IList IEnumerable 存储库实现分页列表

Question

I inherited a project, and asked to implemented Paging across all our Repositories (500+ methods), to show only segments of data on web front end.

Current Repository is below as following. They return Task Lists, IEnumerables etc.

How would we go through, and implement paging for the following Repositories examples?

If I implement following Paged List answer, the repos return IList, not IQueryable. So the answer, would still Retrieve All the Data first (causing performance issue), and then filter it.

https://stackoverflow.com/a/5036023/12425844

Repository:

public Task<List<Product>> GetProductListByProductNumber(int bkProductNumber)
{
    var productData = _context.Product
        .Include(c => c.LkProducttype)
        .Where(c => c.BkProductnumber == bkProductNumber).ToListAsync();
    return productData ;
}


public Task<List<Product>> GetProductListByProductDescription(string productDescription)
{
    var productData = _context.Product
        .Include(c => c.LkProducttype)
        .Where(c => c.ProductDescription == productDescription).ToListAsync();
    return productData;
}

Page List Answer

public PagedList<T> Find(Expression<Func<T,bool>> predicate, int pageNumber, pageSize)
{
   return repository
             .Find()
             .Where(predicate)
             .ToPagedList(pageNumber, pageSize);
}

*Looking for an efficient way, so don't have to Recopy and Paste All the 500+ methods with paging,if possible

If changing all the Repos methods to IQueryable, that may fix the issue. However, was reading Repos should Not return IQueryable per article here Entity Framework Repository Pattern why not return Iqueryable?

Answer 1

If you want to return exactly the data for a page you can use LINQ.Skip and.Take, that will still return a IQueryable

public Task<List<Product>> GetProductListByProductNumberAsync(int bkProductNumber, int pageNumber, int pageSize)
{
    var productData = _context.Product
        .Include(c => c.LkProducttype)
        .Where(c => c.BkProductnumber == bkProductNumber)
        .Skip(pageSize * (pageNumber - 1))
        .Take(pageSize)
        .ToListAsync();
    return productData;
}

The default of this approach is that if new data appears regularly, your pages can lose synchronisation. For example, your query page 2, 25 items and get 25-49. Then 2 new items are inserted and you query page 3, you will get what used to be 48-72 But this is a standard behaviour on most web sites.

Now to address the issue of DRY if you want to keep the existing queries, I would separate first the query itself from the transformation to an asynchronous list:

  private IQueryable<Product> GetProductListByProductNumberQuery(int bkProductNumber)
        {
            var productData = _context.Product
                .Include(c => c.LkProducttype)
                .Where(c => c.BkProductnumber == bkProductNumber);
            return productData;
        }

And then add the way to use the queryable as needed (example with extension methods, but can be done with a class to wrap, or in your repository with 2 ways of invoking a queryable):

  public static class QueryableExtensions
    {
        public static Task<List<T>> ToTask<T>(this IQueryable<T> query) 
        {
            return query.ToListAsync(); // might as well call directly .ToListAsync
        }

        public static Task<List<T>> ToTaskPaged<T>(this IQueryable<T> query, int pageNumber, int pageSize)
        {
            return query
                .Skip(pageSize * (pageNumber-1))
                .Take(pageSize)
                .ToListAsync();
        }
    }

Differing the use of ToListAsync allow to come back to the query to refine it with paging

Whether the queries are public or private will depend on how you want to use them. If you consider that the repository is responsible for providing the queries but not how to run them, then the queries will be public. If you want your repository to only expose wrapped executed queries, then the queries will be private. Good practice is to not return IQueryable, but that would run against the constraint you set that you do not want to create 2 versions of each query (paged, not paged), so with that constraint I would go for exposing the IQueryable. But the articles you link are right in warning that users can start doing insane things with it. If it is exposed to your team only, I think it's fine as long as every one is aware that it is a technical debt. If it is in a public API, then you can't afford to fix it later.