Sprawdziłem implementacje paginacji konkretnie na asp.net mvc i naprawdę czuję, że jest coś mniej wydajnego we wdrożeniach.
Przede wszystkim wszystkie implementacje używają wartości stronicowania jak poniżej.
public ActionResult MostPopulars(int pageIndex,int pageSize)
{
}Rzeczą, w której czuję się źle, jest pageIndex i pageSize całkowicie należące do klasy Pagination, w przeciwnym razie ten sposób wygląda tak funkcjonalnie. Upraszcza to również niepotrzebne przekazywanie parametrów na poziomach aplikacji.
Po drugie, używają interfejsu poniżej.
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; }
} Jeśli chcę przekierować moją paginację na inną akcję, muszę utworzyć nowy model widoku, aby zawrzeć w nim nazwę akcji, a nawet nazwę kontrolera. Innym rozwiązaniem może być przesłanie tego modelu interfejsu do podglądu, a następnie określenie parametru i kontrolera na stałe w metodzie pager jako parametru, ale tracę całkowicie możliwość ponownego użycia mojego widoku, ponieważ jest to ściśle zależne tylko od jednej akcji.
Inną rzeczą jest to, że używają poniżej kodu w widoku
Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)Jeśli modelem jest IPagedList, dlaczego nie zapewniają metody przeciążenia takiej jak @Html.Pager(Model)lub nawet lepszej @Html.Pager(). Wiesz, że znamy typ modelu w ten sposób. Przed popełnieniem błędu, ponieważ korzystałem z Model.PageIndex zamiast Model.PageNumber.
Innym dużym problemem jest to, że mocno polegają na interfejsie IQueryable. Skąd wiedzą, że używam IQueryable w mojej warstwie danych? Spodziewałbym się, że będą działać po prostu ze zbiorami, które utrzymują ignorancję przy wdrażaniu paginacji.
Co jest złego w moich pomysłach na ulepszenia w porównaniu do ich stronicowania? Jaki jest ich powód, aby nie wprowadzać w życie ich paginacji w ten sposób?