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?
źródło
Odpowiedzi:
Jak stwierdził user8685: twój interfejs wydaje się zbędny w stosunku do istniejących rzeczy i zasad MVC.
Spróbuj: informacje wymagane od IPagedList, takie jak indeks strony itp., Powinny zostać zaimplementowane w warstwie logiki biznesowej i przekazane do widoku / strony za pomocą ogólnego modelu, który można przekazać z powrotem do serwera i tam bezpiecznie przesłać i przetworzyć. Dlaczego? Ponieważ to, co tutaj gromadzisz, jest wyraźnie wkładem do twojego systemu informacyjnego i jako takie należy do warstw niższych niż interfejs użytkownika.
Ta droga może nie być najlepszym sposobem i na pewno nie jest najszybsza, ale powinna ułatwić zobaczenie, czego naprawdę potrzebujesz w zakresie abstrakcji i architektury danych, a tym samym pomóc w usunięciu nadmiarowości.
Ponadto istniejący pomocnicy często zawierają zbyt wiele narzutów, aby można je było łatwo wykorzystać, a czasem zaciemniają duży obraz.
źródło
Nie korzystałem z tej IPagedList ani pomocnika, ale to moje zdanie:
MostPopular(int pageIndex,int pageSize)Wyraźna interfejs stwierdzając: Wrócę tylko strony z mostpopular rzeczy. Wyraźnie mówisz mi, która strona i jej rozmiar.Jeśli zastosowali metodę kontrolera,
MostPopular(IPagedList<T> page)interfejs staje się bardziej mylący. Podajesz kontrolerowi całkowitą liczbę przedmiotów, czy nie?Gdy kontroler pobiera określony stronicowany wycinek danych, zwykle może odkryć różne inne dane, na przykład liczbę wszystkich elementów. W tym momencie sensowne jest zwracanie takich danych do widoku, aby mógł selektywnie korzystać z niektórych z nich.
To nie znaczy, że IPagedList jest modelu, to może równie dobrze być częścią modelu (właściwość na nim). Prawdopodobnie dlatego nie występuje przeciążenie bez parametrów.
Mogli dodać IPagedList jako przeciążenie, ale wtedy przekazalibyśmy zestaw (stronicowany fragment danych) do małego pomocnika pagera, który nie potrzebuje samych danych. Musi tylko wiedzieć, ile stron / pozycji w tej chwili jesteś, aby mógł podświetlić numer strony i tym podobne. Powiedziałbyś pomocnikowi o wiele więcej niż musi wiedzieć, aby wykonać swoją pracę. To, jak teraz działa, ma dolne sprzęgło, co jest dobrą rzeczą.
źródło
Biorąc pod uwagę, że to, o co klient prosi o numer strony, i to, co najprawdopodobniej się zmieni, to rozmiar strony:
To całkiem rozsądny sposób na zrobienie tego. Widziałem różne warianty, w których zastosowano ennum (pierwszy, następny, poprzedni, ostatni), ale tak naprawdę to po prostu niezręczny sposób na powiedzenie „pageIndex”.
Chciałbym powtórzyć, że rozmiar strony będzie i powinien się bardzo różnić, w zależności od zaangażowanego użytkownika powinieneś uzyskać różne ustawienia domyślne dla telefonów komórkowych, przenośnych i dużych stacji roboczych, a ponadto w wielu przypadkach rozsądne jest, aby użytkownik końcowy mógł wybrać, ile elementów stanowi Strona.
Wiem, że skutkuje to przekazywaniem wielu parametrów w ramach MVC, ale cała koncepcja stronicowania psuje MVC - logika biznesowa musi wiedzieć o prezentacji, aby stronicowanie działało, więc zawsze będzie bałagan.
źródło