Имеет ли смысл возвращать PageList <T> из моей модели, если я не использую ленивую загрузку LINQ?

Question

Я работаю над системой обмена сообщениями для моего сайта, написанного в ASP.NET MVC. Прямо сейчас, я пытаюсь сгладить разбивку на страницы для просмотров Inbox/Sent.

Я наткнулся на Rob Connery's PagedList<T>, что кажется хорошим решением проблемы.

Однако одно отличие между моим прецедентом и Робом заключается в том, что я не возвращаю IQueryable из своей модели и все запросы, которые я запускаю с .ToList() после них (после чего возвращаю IEnumerable), чтобы гарантировать, что мой запрос выполняется при вызове метода Model.

Из-за этой разницы, имеет ли смысл использовать его PagedList<T>? Я просто хочу вернуть подмножество итоговых результатов, а также некоторые другие свойства, такие как «HasNextPage», «Total Count» и т. Д.

Однако, поскольку я не позволяю классу PagedList напрямую обращаться к IQueryable, Мне интересно, должен ли я просто создать свой собственный базовый класс с теми свойствами, которые мне нужны?

Я знаю, как принять конкретную страницу результатов с помощью LINQ:

public IEnumerable<Entities.Message> GetInboxMessages(int userID, int pageSize, int pageIndex) 
{ 
    using (MainDataContext db = new MainDataContext()) 
    { 
     var messages = (from m in db.Messages 
         join o in db.MessageRecipients on m.MessageID equals o.MessageID 
         orderby m.DateSent 
         select new Entities.Message 
         { 
          // ... 

          }).Skip(pageIndex * pageSize).Take(pageSize).ToList(); 

      return messages; 
     } 
    } 

Но без другой информации, мне нужно о HavingNextPage, TotalItemsCount и т.д.

Что я должен делать в этом случае? Могу ли я использовать выше PagedList<T>, хотя я не планирую делать Lazy Loading? Должен ли я просто создать свою собственную?

Answer 1

Вы все еще можете использовать PagedList. Поддержка IQueryable - это всего лишь одна часть, все остальные биты будут работать нормально.