Domanda sulla progettazione delle attuali implementazioni di impaginazione

12

Ho controllato le impaginazioni di impaginazione su asp.net mvc in particolare e sento davvero che c'è qualcosa di meno efficiente nelle implementazioni.

Prima di tutto tutte le implementazioni usano valori di impaginazione come sotto.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

La cosa che mi sembra sbagliata è che pageIndex e pageSize dovrebbero essere tutti membri della classe di Pagination altrimenti in questo modo sembra un modo molto funzionale. Inoltre semplifica il passaggio di parametri non richiesti in livelli di applicazione.

La seconda cosa è che usano l'interfaccia di sotto.

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, devo creare un nuovo modello di visualizzazione per racchiudere il nome dell'azione o persino il nome del controller. Un'altra soluzione può essere che l'invio di questo modello interfacciato per visualizzare quindi specificare l'azione e il controller codificati 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 forniscono un metodo di overload come @Html.Pager(Model) o meglio ancora uno è @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 dipendono strongmente dall'interfaccia IQueryable. Come sanno che uso IQueryable nel mio livello dati? Mi sarei aspettato che funzionassero semplicemente con collezioni che ignorano la persistenza nell'impaginazione.

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?

    
posta Freshblood 12.06.2011 - 11:53
fonte

3 risposte

1

Come dichiarato dall'utente8685: la tua interfaccia sembra ridondante ai principi e ai principi MVC esistenti.

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

Questo modo potrebbe non essere il modo migliore per andare e non è certamente il più veloce, ma dovrebbe fare è più facile vedere ciò di cui hai realmente bisogno in termini di astrazione e architettura dei dati e quindi aiutarti a rimuovere la ridondanza.

Inoltre, gli helper esistenti spesso contengono troppo overhead per un utilizzo semplice e talvolta offuscano il quadro generale.

    
risposta data 08.08.2012 - 16:56
fonte
0

Non ho usato questo IPagedList o hely thingy, ma questa è la mia opinione:

Il MostPopular(int pageIndex,int pageSize) è un'interfaccia esplicita che afferma: restituirò solo pagine di 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 una specifica porzione di dati paginata, in genere è in grado di rilevare vari altri dati, come il numero totale di elementi. A questo punto ha senso restituire tali dati a una vista, quindi può usarne selettivamente alcuni.

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

Potrebbero aver aggiunto IPagedList come un sovraccarico, ma poi si passerebbe un set (un blocco di dati paginato) a un piccolo helper del cercapersone che non ha bisogno dei dati effettivi. Ha solo bisogno di sapere quante pagine / articoli e dove sei al momento in modo che possa evidenziare il numero di pagina e così via. Diresti l'aiutante molto più di quanto abbia bisogno di sapere per fare il suo lavoro. Il modo in cui funziona ora ha un accoppiamento più basso, che è una buona cosa.

    
risposta data 22.02.2012 - 23:55
fonte
0

Dato che il client chiede un numero di pagina e ciò che è più probabile che il client vari è la dimensione della pagina, penso:

public ActionResult MostPopulars(int pageIndex,int pageSize)

È un modo abbastanza ragionevole per farlo. Ho visto variazioni in cui è stato usato un ennum di (first, next, prev, last) ma in realtà è solo un modo imbarazzante di dire "pageIndex".

Vorrei ribadire che la dimensione della pagina varia e dovrebbe variare molto, a seconda dello spettatore coinvolto dovresti ottenere valori predefiniti diversi per cellulari, portatili e workstation con schermo grande, inoltre, in molti casi è ragionevole lasciare che l'utente scelga come molti elementi costituiscono una pagina.

So che questo comporta molti passaggi di parametri all'interno di un framework MVC, ma l'intero concetto di interruzione di pagina MVC - la logica di business deve conoscere la presentazione affinché il paging funzioni in modo che sia sempre disordinato .

    
risposta data 23.04.2012 - 03:45
fonte

Leggi altre domande sui tag