Question sur la conception des implémentations de pagination actuelles


12

J'ai vérifié les implémentations de pagination sur asp.net mvc spécifiquement et je pense vraiment qu'il y a quelque chose de moins efficace dans les implémentations.

Tout d'abord, toutes les implémentations utilisent des valeurs de pagination comme ci-dessous.

public ActionResult MostPopulars(int pageIndex,int pageSize)
{

}

La chose que je me sens mal est pageIndex et pageSize devraient être totalement membres de la classe de pagination, sinon cette façon semble tellement fonctionnelle. Il simplifie également le passage de paramètres inutiles dans les niveaux d'application.

La deuxième chose est qu'ils utilisent l'interface ci-dessous.

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

Si je veux router ma pagination vers une action différente, je dois donc créer un nouveau modèle de vue pour y encapsuler le nom de l'action ou même le nom du contrôleur. Une autre solution peut consister à envoyer ce modèle interfacé à la vue, puis à spécifier l'action et le contrôleur codés en dur dans la méthode de pageur comme paramètre, mais je perds totalement la réutilisation de ma vue car elle dépend strictement d'une seule action.

Une autre chose est qu'ils utilisent le code ci-dessous en vue

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

Si le modèle est IPagedList, pourquoi ils ne fournissent pas une méthode de surcharge comme @Html.Pager(Model)ou mieux encore @Html.Pager(). Vous savez que nous connaissons le type de modèle de cette façon. Avant je faisais une erreur parce que j'utilisais Model.PageIndex au lieu de Model.PageNumber.

Un autre gros problème est qu'ils dépendent fortement de l'interface IQueryable. Comment savent-ils que j'utilise IQueryable dans ma couche de données? Je m'attendais à ce qu'ils fonctionnent simplement avec des collections qui ignorent la persistance de la mise en œuvre de la pagination.

Quel est le problème avec mes idées d'amélioration par rapport à leurs implémentations de pagination? Quelle est leur raison de ne pas mettre en œuvre leurs paginations de cette façon?


Cela me semble assez complexe. Non pas que j'ai bien compris quel est exactement le problème, mais ... avez-vous vraiment besoin d'utiliser les aides intégrées? Je ne savais même pas qu'ils avaient un téléavertisseur. J'ai développé une collection de mes propres assistants depuis l'époque de MVC 1 Beta après mes premières (et échouées) tentatives de s'entendre avec les assistants intégrés. Je vous recommande la même chose. Si vous avez du mal avec ces assistants, ce n'est pas mieux que WebForms où vous aviez du mal avec les contrôles du serveur.

ASP.NET MVC ne dispose d'aucun assistant de pagination intégré, mais il existe des implémentations de pagination tierces.
Freshblood

Merci pour ces informations. La question est, pourquoi en avez-vous besoin? Ce n'est pas un effort pour l'implémenter par vous-même, tout comme vous le souhaitez.

Je voulais juste savoir qu'il y avait quelque chose de mal dans mes idées. Ai-je brisé certains principes de base sinon pourquoi tous ont-ils suivi la même conception sur leurs implémentations .. je ne comprends pas
Freshblood

si un code ne peut pas résoudre le problème d'un programmeur, le code n'a aucune valeur, il vaut mieux éviter de l'utiliser.
Shaheer

Réponses:


1

Comme l'a déclaré user8685: votre interface semble redondante par rapport aux principes et principes MVC existants.

Essayez ceci: les informations dont vous avez besoin sur IPagedList, comme l'index de page, etc. doivent être implémentées dans la couche de logique métier et alimentées à la vue / page via un modèle générique qui peut être renvoyé au serveur et casté et traité en toute sécurité. Pourquoi? Parce que ce que vous collectez ici est clairement une entrée dans votre système d'information et en tant que tel appartient à des couches inférieures à l'interface utilisateur.

Cette méthode n'est peut-être pas la meilleure solution et n'est certainement pas la plus rapide, mais elle devrait permettre de voir plus facilement ce dont vous avez vraiment besoin en termes d'abstraction et d'architecture de données et ainsi vous aider à supprimer la redondance.

En outre, les assistants existants contiennent souvent trop de frais généraux pour une utilisation simple et masquent parfois la vue d'ensemble.


0

Je n'ai pas utilisé cette IPagedList ou ce truc d'aide, mais voici ma position:

Il MostPopular(int pageIndex,int pageSize)s'agit d'une interface explicite indiquant: je ne retournerai que des pages de choses MostPopular. Vous me dites explicitement quelle page et sa taille.

S'ils avaient fait une méthode de contrôleur, MostPopular(IPagedList<T> page)l'interface devient plus confuse. Dites-vous au contrôleur le nombre total d'articles ou non?

Lorsque le contrôleur récupère votre tranche spécifique paginée des données, il peut généralement découvrir diverses autres données, comme le nombre total d'éléments. À ce stade, il est logique de renvoyer ces données à une vue, afin qu'il puisse en utiliser certaines de manière sélective.

Cela ne signifie pas que IPagedList est le modèle, il pourrait tout aussi bien faire partie d' un modèle (une propriété sur celui-ci). C'est probablement pourquoi il n'y a pas de surcharge sans paramètre.

Ils auraient pu ajouter IPagedList en tant que surcharge, mais vous transmettriez ensuite un ensemble (un bloc de données paginé) à un petit assistant de pagination qui n'a pas besoin des données réelles elles-mêmes. Il a juste besoin de savoir combien de pages / éléments et où vous vous trouvez en ce moment pour pouvoir mettre en évidence le numéro de page, etc. Vous en diriez beaucoup plus à l'assistant qu'il doit savoir pour faire son travail. La façon dont cela fonctionne maintenant a un couplage inférieur, ce qui est une bonne chose.


Je voulais juste dire que le paramètre de méthode d'action pourrait être un objet qui a une propriété nommée PageIndex et PageSize, de cette façon, nous pourrions valider le modèle facilement parce que quelqu'un peut pousser une énorme quantité de taille de page pour attaquer les performances du serveur. Et s'ils fourniraient une surcharge sans paramètre, une surcharge sans paramètre serait utilisable lorsque le modèle est IPagedList. Il n'y a rien de mal si je passe plus de données que ce dont l'aide a besoin. Il n'y a pas de règle stricte comme meilleure pratique.
Freshblood

0

Étant donné que ce que le client demande pour le numéro de page et ce que le client est le plus susceptible de varier est la taille de la page, je pense:

public ActionResult MostPopulars(int pageIndex,int pageSize)

Est une façon assez raisonnable de le faire. J'ai vu des variations où un ennum de (premier, suivant, précédent, dernier) a été utilisé, mais c'est vraiment une façon maladroite de dire "pageIndex".

Je réitère que la taille de la page variera et devrait varier considérablement, en fonction de la visionneuse impliquée, vous devriez obtenir des valeurs par défaut différentes pour les mobiles, les portables et les postes de travail sur grand écran, de plus, dans de nombreux cas, il est judicieux de laisser l'utilisateur final choisir le nombre d'éléments constituant une feuille.

Je sais que cela entraîne un grand nombre de paramètres passant dans un cadre MVC, mais le concept entier de la pagination rompt MVC - votre logique métier doit être au courant de la présentation pour que la pagination fonctionne, donc elle sera toujours désordonnée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.