Я проверил реализации разбиения на страницы на asp.net mvc специально, и я действительно чувствую, что есть кое-что менее эффективное в реализациях.
Прежде всего, все реализации используют значения нумерации страниц, как показано ниже.
public ActionResult MostPopulars(int pageIndex,int pageSize)
{
}Единственное, что я чувствую неправильно, это то, что pageIndex и pageSize должны быть членами класса Pagination, иначе этот способ выглядит намного функциональнее. Также это упрощает ненужный переход параметров в уровни приложения.
Во-вторых, они используют интерфейс ниже.
public interface IPagedList<T> : IList<T>
{
int PageCount { get; }
int TotalItemCount { get; }
int PageIndex { get; }
int PageNumber { get; }
int PageSize { get; }
bool HasPreviousPage { get; }
bool HasNextPage { get; }
bool IsFirstPage { get; }
bool IsLastPage { get; }
} Если я хочу направить свою нумерацию страниц на другие действия, мне нужно создать новую модель представления для инкапсуляции имени действия в ней или даже имени контроллера. Другое решение может состоять в том, что отправка этой интерфейсной модели для просмотра, а затем в качестве параметра указывает действие и контроллер, жестко запрограммированные в методе пейджера, но я теряю возможность повторного использования моего представления, поскольку оно строго зависит только от одного действия.
Другое дело, что они используют код ниже
Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)Если модель IPagedList, почему они не предоставляют такой метод перегрузки, как @Html.Pager(Model)или даже лучше @Html.Pager(). Вы знаете, что мы знаем тип модели таким образом. Прежде чем я делал ошибку, потому что я использовал Model.PageIndex вместо Model.PageNumber.
Еще одна большая проблема - они сильно полагаются на интерфейс IQueryable. Откуда они знают, что я использую IQueryable в своем слое данных? Я ожидал бы, что они работают просто с коллекциями, которые сохраняют невежественность реализации реализации нумерации страниц.
Что плохого в моих идеях по улучшению их реализации нумерации страниц? Какова их причина, чтобы не осуществлять свои нумерации страниц таким образом?
источник
Ответы:
Как заявил user8685: ваш интерфейс кажется избыточным для существующих вещей и принципов MVC.
Попробуйте это: информация, которую вы запрашиваете из IPagedList, например, индекс страницы и т. Д., Должна быть реализована на уровне бизнес-логики и передаваться в представление / страницу с помощью общей модели, которая может быть возвращена на сервер и безопасно приведена и обработана там. Почему? Потому что то, что вы собираете здесь, явно является входом для вашей информационной системы и, как таковое, относится к уровням ниже, чем пользовательский интерфейс.
Этот путь может быть не самым лучшим и, конечно, не самым быстрым, но он должен облегчить понимание того, что вам действительно нужно с точки зрения абстракции и архитектуры данных, и, таким образом, помочь вам устранить избыточность.
Кроме того, существующие помощники часто содержат слишком много служебных данных для простого использования и иногда запутывают общую картину.
источник
Я не использовал этот IPagedList или вспомогательный инструмент, но это мое мнение:
Это
MostPopular(int pageIndex,int pageSize)явный интерфейс, утверждающий: я буду только возвращать страницы вещей MostPopular. Вы явно говорите мне, какая страница и ее размер.Если они сделали метод контроллера,
MostPopular(IPagedList<T> page)интерфейс становится более запутанным. Вы говорите контролеру об общем количестве предметов или нет?Когда контроллер извлекает ваш конкретный выгружаемый фрагмент данных, он обычно может обнаруживать различные другие данные, например, общее количество элементов. На этом этапе имеет смысл возвращать такие данные в представление, чтобы они могли выборочно использовать некоторые из них.
Это вовсе не означает , что IPagedList является модель, она может точно также быть частью модели (свойство на нем). Вероятно, поэтому нет перегрузки без параметров.
Они могли бы добавить IPagedList в качестве перегрузки, но тогда вы бы передавали набор (разбитый на куски данных) маленькому помощнику на пейджер, которому сами данные не нужны. Ему просто нужно знать, сколько страниц / элементов и где вы находитесь в данный момент, чтобы он мог выделить номер страницы и тому подобное. Вы бы сказали помощнику гораздо больше, чем он должен знать, чтобы выполнять свою работу. То, как это работает, теперь имеет более низкую связь, что хорошо.
источник
Учитывая, что клиент запрашивает номер страницы и что клиент, скорее всего, будет менять, это размер страницы, я думаю:
Это довольно разумный способ сделать это. Я видел варианты, в которых использовался ennum (first, next, prev, last), но на самом деле это просто неловкий способ сказать "pageIndex".
Я хотел бы повторить, что размер страницы будет и должен сильно варьироваться, в зависимости от вовлеченного зрителя, вы должны получить различные значения по умолчанию для мобильных телефонов, портативных компьютеров и рабочих станций с большим экраном, плюс во многих случаях целесообразно позволить конечному пользователю выбирать, сколько элементов составляют страница.
Я знаю, что это приводит к большому количеству передачи параметров в рамках MVC, но сама концепция разбиения на страницы разбивает MVC - ваша бизнес-логика должна знать о представлении, чтобы подкачка работала, поэтому она всегда будет грязной.
источник