Frage zum Design aktueller Paginierungsimplementierungen

Ich habe Paginierungsimplementierungen auf asp.net mvc speziell geprüft und ich habe wirklich das Gefühl, dass Implementierungen etwas weniger effizient sind.

Zuallererst verwenden Implementierungen Paginierungswerte wie unten.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

Die Sache, die ich falsch fühle, ist pageIndex und pageSize sollten total Mitglied der Paginierungsklasse sein, andernfalls sieht diese Weise so funktionell aus. Es vereinfacht auch unnötige Parameterübergaben in Anwendungsebenen.

Die zweite Sache ist, dass sie unter der Schnittstelle verwenden.

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; }
} 

Wenn ich meine Paginierung auf eine andere Aktion umleiten möchte, muss ich ein neues Ansichtsmodell erstellen, um den Aktionsnamen oder sogar den Controllernamen darin einzuschließen. Eine andere Lösung kann sein, dass Sie dieses Schnittstellenmodell zur Ansicht senden und dann die Aktion und den Controller als Parameter in der Pager-Methode fest codieren. Ich verliere jedoch die völlige Wiederverwendbarkeit meiner Ansicht, da diese ausschließlich von nur einer Aktion abhängt.

Eine andere Sache ist, dass sie den folgenden Code in view verwenden

Html.Pager(Model.PageSize, Model.PageNumber, Model.TotalItemCount)

Wenn das Modell IPagedList ist, warum bieten sie keine Überladungsmethode wie @Html.Pager(Model)oder noch besser eine @Html.Pager(). Sie wissen, dass wir den Modelltyp auf diese Weise kennen. Vorher habe ich einen Fehler gemacht, weil ich Model.PageIndex anstelle von Model.PageNumber verwendet habe.

Ein weiteres großes Problem ist, dass sie stark auf die IQueryable-Schnittstelle angewiesen sind. Woher wissen sie, dass ich IQueryable in meiner Datenschicht verwende? Ich würde erwarten, dass sie einfach mit Sammlungen arbeiten, die die Implementierung von Paginierungspersistenz ignorieren.

Was ist falsch an meinen Verbesserungsideen gegenüber ihren Paginierungsimplementierungen? Was ist ihr Grund, ihre Paginierungen nicht auf diese Weise umzusetzen?

Wie user8685 feststellte: Ihre Schnittstelle scheint zu vorhandenen MVC-Sachen und -Prinzipien überflüssig zu sein.

Versuchen Sie Folgendes: Informationen, die Sie von IPagedList benötigen, wie Seitenindex usw., sollten in der Geschäftslogikebene implementiert und der Ansicht / Seite über ein generisches Modell zugeführt werden, das an den Server zurückgespeist und dort sicher umgewandelt und verarbeitet werden kann. Warum? Denn was Sie hier sammeln, ist eindeutig eine Eingabe in Ihr Informationssystem und gehört als solche zu Schichten, die niedriger als die Benutzeroberfläche sind.

Dieser Weg ist möglicherweise nicht der beste und mit Sicherheit auch nicht der schnellste, er sollte jedoch die Ermittlung der tatsächlich benötigten Informationen in Bezug auf Abstraktion und Datenarchitektur erleichtern und Ihnen somit dabei helfen, Redundanzen zu beseitigen.

Außerdem enthalten vorhandene Helfer häufig zu viel Aufwand für die einfache Verwendung und verschleiern manchmal das Gesamtbild.

Ich habe dieses IPagedList- oder Hilfsprogramm nicht verwendet, aber dies ist meine Einstellung:

Das MostPopular(int pageIndex,int pageSize)ist eine explizite Schnittstelle, die besagt: Ich werde nur Seiten von MostPopular-Dingen zurückgeben. Sie sagen mir ausdrücklich, welche Seite und welche Größe sie hat.

Wenn sie eine Controller-Methode erstellt haben, wird MostPopular(IPagedList<T> page)die Schnittstelle verwirrender. Teilen Sie dem Controller die Gesamtmenge der Elemente mit oder nicht?

Wenn der Controller einen bestimmten ausgelagerten Teil der Daten abruft, kann er in der Regel verschiedene andere Daten ermitteln, z. B. wie viele Elemente insgesamt vorhanden sind. An dieser Stelle ist es sinnvoll, solche Daten an eine Ansicht zurückzugeben, damit sie teilweise selektiv verwendet werden können.

Dies bedeutet nicht, dass IPagedList das Modell ist, es könnte genauso gut Teil eines Modells sein (eine Eigenschaft darauf). Dies ist wahrscheinlich der Grund, warum es keine parameterlose Überlastung gibt.

Sie hätten IPagedList als Überladung hinzufügen können, aber dann würden Sie einen Satz (einen ausgelagerten Datenblock) an einen kleinen Pager-Helfer übergeben, der die eigentlichen Daten nicht benötigt. Es muss nur wissen, wie viele Seiten / Elemente vorhanden sind und wo Sie sich gerade befinden, damit die Seitenzahl und dergleichen hervorgehoben werden können. Sie würden dem Helfer weit mehr sagen, als er wissen muss, um seine Arbeit zu erledigen. Die Art und Weise, wie es jetzt funktioniert, hat eine geringere Kopplung, was eine gute Sache ist.

Angesichts der Tatsache, dass der Kunde nach der Seitenzahl fragt und die Wahrscheinlichkeit besteht, dass der Kunde davon abweicht, ist die Seitengröße meiner Meinung nach:

public ActionResult MostPopulars(int pageIndex,int pageSize)

Ist ein ziemlich vernünftiger Weg, dies zu tun. Ich habe Variationen gesehen, in denen eine ganze Reihe von (first, next, prev, last) verwendet wurde, aber es ist wirklich nur eine unangenehme Art, "pageIndex" zu sagen.

Ich möchte noch einmal betonen, dass die Seitengröße sehr unterschiedlich sein wird und sollte. Je nach Betrachter sollten Sie unterschiedliche Standardeinstellungen für Handys, tragbare Geräte und Großbild-Workstations verwenden. In vielen Fällen ist es sinnvoll, den Endbenutzer die Anzahl der Elemente bestimmen zu lassen eine Seite.

Ich weiß, dass dies zu einer Menge Parameterübergabe innerhalb eines MVC-Frameworks führt, aber das gesamte Konzept des Paging unterbricht MVC - Ihre Geschäftslogik muss sich mit Präsentation auskennen, damit das Paging funktioniert und es immer chaotisch wird.