Inspiriert von dies habe ich Folgendes gemacht:
ISortable
%Vor%IPageable
%Vor%Seitenausrichtung
%Vor%Das obige funktioniert. Großer Erfolg! :)
Ich habe jedoch ein Problem bei der Implementierung der Methode .ThenBy() festgestellt. Das Problem ist, dass .ThenBy() nur zugänglich sein sollte, wenn .OrderBy() aufgerufen wurde.
Ich habe festgestellt, dass IQueryable.OrderBy ein IOrderedQueryable zurückgibt, und das ist der Zugriff auf .ThenBy() kommt von. Aber um meine jetzige Lösung funktionieren zu lassen, müsste ich ein IOrderedPageable und ein neues OrderedPagable machen, um damit zu arbeiten. Das OrderedPagable wäre eine fast exakte Kopie von Pageable, was wirklich ein sehr schlechtes Design ist.
Ich bezweifle stark, dass das in LINQ so gemacht wird. Meine Frage ist also, wie haben sie das gemacht? Ich bin sehr neugierig:)
Eine Sache, die ich bemerkt habe, ist, dass so ziemlich alle LINQ-Methoden Erweiterungsmethoden sind, ist das Teil des "Tricks":)?
Es klingt wie Ihre Klasse OrderedPageable könnte eine Unterklasse von Pageable sein und zusätzlich die IOrderedPageable Schnittstelle implementieren.
Der Vererbungsansatz scheint sinnvoll zu sein, da alles, was Pageable verarbeitet, wahrscheinlich in der Lage ist, OrderedPageable auf dieselbe Weise zu behandeln.
Indem Sie Ihre Schnittstellen leicht ändern und einen ähnlichen Ansatz für die Schnittstellenvererbung verwenden, können Sie die Funktionalität erreichen, die Sie mit unveränderbaren abfragbaren Klassen und Erweiterungsmethoden suchen.
Meiner Meinung nach ist die Verwendung klarer und konsistenter mit LINQ.
Beispiele:
%Vor%Ich habe das nicht getestet, aber das Konzept sollte funktionieren. Beachten Sie Folgendes:
SourceQuery -Eigenschaft von IPageableQuery für die Verwendung in PageableExtensions verfügbar machen, da Ihr Abfrageanbieter Abfragen für diesen neuen PageableQuery -Typ möglicherweise nicht erfolgreich übersetzt. Schnittstellen:
%Vor%Implementierungen:
%Vor%Erweiterungsmethoden:
%Vor% Mein vorgeschlagener Entwurf dafür wäre, explizit zu machen, dass Ihre Methoden tatsächlich das Quellobjekt mutieren und LINQ-Methodennamen absichtlich nicht spiegeln, um Verwirrung zu vermeiden. Ich habe die IPageable -Schnittstelle und eine Menge anderer Dinge aus Gründen der Klarheit weggelassen, da der Code schon etwas lang ist:
Beachten Sie, dass die Quellabfrage unverändert bleibt, sodass Sie die Parameter vor dem Auflisten der Elemente ändern können. Dadurch können Sie auch das Verkettungsverhalten implementieren, indem Sie ein neues Pageable basierend auf dem aktuellen% ce_de% in den Methoden, die das tun, zurückgeben, aber es würde den Code noch klüger machen, da Sie create a erstellt hätten Kopieren Sie den Konstruktor und fügen Sie Code hinzu, um diese abgeleiteten Objekte zu erstellen.
Ich glaube auch, dass der störende redundante Code in this mit einigen FP-Ansätzen umgestaltet werden könnte (oder zumindest heruntergedreht werden könnte), aber es ist wahrscheinlich einfacher, ihn zu lesen.