Domanda sulla progettazione delle attuali implementazioni di impaginazione

Ho verificato in modo specifico le implementazioni di impaginazione su asp.net mvc e credo davvero che ci sia qualcosa di meno efficiente nelle implementazioni.

Innanzitutto le implementazioni utilizzano valori di impaginazione come di seguito.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

La cosa che mi sbaglio è pageIndex e pageSize totalmente dovrebbero essere membri della classe di paginazione, altrimenti in questo modo sembra molto funzionale. Inoltre semplifica il passaggio di parametri inutili nei livelli di applicazione.

La seconda cosa è che usano l'interfaccia sottostante.

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

Se voglio indirizzare la mia impaginazione a un'azione diversa, quindi devo creare un nuovo modello di vista per incapsulare il nome dell'azione in esso o anche il nome del controller. Un'altra soluzione può essere quella di inviare questo modello interfacciato per visualizzare quindi specificare l'azione e il controller hard coded nel metodo cercapersone come parametro ma sto perdendo totalmente la riutilizzabilità della mia vista perché dipende strettamente da una sola azione.

Un'altra cosa è che usano sotto il codice in vista

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

Se il modello è IPagedList, perché non fornisce un metodo di sovraccarico simile @Html.Pager(Model)o addirittura migliore @Html.Pager(). Sai che conosciamo il tipo di modello in questo modo. Prima stavo facendo un errore perché stavo usando Model.PageIndex invece di Model.PageNumber.

Un altro grosso problema è che si basano fortemente sull'interfaccia IQueryable. Come fanno a sapere che utilizzo IQueryable nel mio livello dati? Mi sarei aspettato che funzionassero semplicemente con raccolte che non tengono conto della persistenza dell'implementazione della paginazione.

Cosa c'è di sbagliato nelle mie idee di miglioramento rispetto alle loro implementazioni di impaginazione? Qual è la loro ragione per non implementare le loro impaginazioni in questo modo?

Come affermato da user8685: la tua interfaccia sembra ridondante ai contenuti e ai principi MVC esistenti.

Prova questo: le informazioni richieste da IPagedList, come l'indice di pagina, ecc., Dovrebbero essere implementate nel livello di logica aziendale e inviate alla vista / pagina attraverso un modello generico che può essere inviato al server e trasmesso in modo sicuro ed elaborato lì. Perché? Perché ciò che stai raccogliendo qui chiaramente è un input per il tuo sistema informativo e come tale appartiene a livelli inferiori all'interfaccia utente.

In questo modo potrebbe non essere il modo migliore di procedere e non è certamente il più rapido, ma dovrebbe rendere più semplice la visualizzazione di ciò di cui si ha realmente bisogno in termini di astrazione e architettura dei dati e quindi aiutare a rimuovere la ridondanza.

Inoltre, gli helper esistenti spesso contengono troppe spese generali per un semplice utilizzo e talvolta offuscano il quadro generale.

Non ho usato questa IPagedList o cosa dell'helper ma questa è la mia opinione:

Il MostPopular(int pageIndex,int pageSize)è un'interfaccia esplicita affermando: Tornerò solo pagine di cose mostPopular. Mi dici esplicitamente quale pagina e le sue dimensioni.

Se avessero creato un metodo controller MostPopular(IPagedList<T> page)l'interfaccia diventa più confusa. Stai dicendo al controller la quantità totale di articoli o no?

Quando il controller recupera la specifica porzione di dati paginata, in genere può rilevare vari altri dati, come il numero totale di elementi. A questo punto ha senso restituire tali dati a una vista, in modo che possano utilizzarli in modo selettivo.

Questo non significa che IPagedList sia il modello, potrebbe anche far parte di un modello (una proprietà su di esso). Questo è probabilmente il motivo per cui non esiste un sovraccarico senza parametri.

Avrebbero potuto aggiungere IPagedList come sovraccarico, ma poi si passerebbe un set (un blocco di dati di paging) a un piccolo aiutante di cercapersone che non ha bisogno dei dati effettivi stessi. Deve solo sapere quante pagine / elementi e dove ti trovi in ​​questo momento in modo da poter evidenziare il numero di pagina e così via. Diresti all'aiutante molto più di quanto abbia bisogno di sapere per fare il suo lavoro. Il modo in cui funziona ora ha un accoppiamento inferiore, il che è una buona cosa.

Dato che ciò che il cliente richiede un numero di pagina e ciò che il cliente ha maggiori probabilità di variare è la dimensione della pagina penso:

public ActionResult MostPopulars(int pageIndex,int pageSize)

È un modo abbastanza sensato di farlo. Ho visto variazioni in cui è stato usato un ennum di (primo, successivo, precedente, ultimo) ma in realtà è solo un modo imbarazzante di dire "pageIndex".

Ribadirei che la dimensione della pagina varierà e dovrebbe variare molto, a seconda del visualizzatore coinvolto dovresti ottenere impostazioni predefinite diverse per cellulari, portatili e workstation su grande schermo, inoltre, in molti casi è sensato lasciare che l'utente finale scelga quanti elementi costituiscono una pagina.

So che questo porta a un sacco di parametri che passano all'interno di un framework MVC, ma l'intero concetto di paging rompe MVC - la tua logica aziendale deve conoscere la presentazione affinché il paging funzioni, quindi sarà sempre disordinato.