Я перевірив реалізацію сторінки на asp.net mvc спеціально, і я дійсно вважаю, що є щось менш ефективне в реалізації.
Перш за все, у всіх реалізаціях використовуються значення сторінок як нижче.
public ActionResult MostPopulars(int pageIndex,int pageSize)
{
}Те, що я вважаю неправильним, це pageIndex і pageSize повністю повинні бути учасниками класу сторінки, інакше цей спосіб виглядає настільки функціонально. Крім того, це спрощує пропуск зайвих параметрів у рівні застосування.
Друге, що вони використовують нижче інтерфейс.
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 у моєму рівні даних? Я б очікував, що вони працюють просто з колекціями, які зберігають постійність впровадження сторінок ігнорування.
Що не так у моїх ідеях удосконалення щодо їх реалізації сторінок? Яка їхня причина не реалізувати свої сторінки таким чином?