2010-09-14 10 views
0

J'ai un ArrayList de Book s tirés de différents Merchant s et classés en Java, en fonction des préférences de l'utilisateur, selon les commentaires des prix ou des clients:Décider d'une stratégie pour paginer annonces Réserver sans SQL

List<Book> books = new ArrayList<Book>(); 

Cette exige de moi de garder en mémoire une grande partie des données stockées en tant qu'objets Java à tout moment. Maintenant que j'ai besoin de paginer ces données dans des listes qui couvrent plusieurs pages Web et permettre à un utilisateur de cliquer sur un lien de page numéroté pour accéder à ce segment de données, quelle est la meilleure façon de le faire?

Mon idée était d'avoir peut-être 25 annonces de livres par page et plutôt que des liens d'utilisation qui transmettent les données de formulaire comme une demande GET des paramètres d'URL, les hyperliens de numéros de page se soumettre à nouveau simplement le formulaire, en passant la demande numéro de page sous la forme d'un autre paramètre POST.

<input type="hidden" id="pageNumber" value="0"> 
<a href="#" onClick="pageNumber=5; this.form.submit()">Page 5</a> 

Dans cette page cas 5 serait tout simplement un ensemble de 25 enregistrements à partir de la 125e (5 * 25) dans le dossier ArrayList et se terminant au dossier 149e dans le ArrayList.

Y a-t-il une meilleure façon de procéder?

Répondre

3

Refactorisez votre application pour laisser, par ex. Hibernate extrait les données de la base de données sous-jacente. Hibernate peut faire tout le tri et la pagination sans avoir à tout garder en mémoire à tout moment.

1

IMO la demande étant un GET ou POST ne devrait pas faire beaucoup de différence, donc je dirais que tout ce qui flotte votre bateau (tête de blindage de réfutations RESTful). La grande chose qui m'inquiète encore est de garder cette liste en mémoire. Le retirer de différents marchands semble être un bon argument pour ne pas le retrouver à chaque fois qu'une page est demandée, mais personnellement, je considérerais de stocker ces résultats dans une base de données locale de toute façon, même temporairement. Garder autant de données en mémoire sur votre serveur d'application aura des conséquences lorsque vous avez beaucoup d'utilisateurs simultanés.

0

J'ai une bibliothèque open source pour traiter le problème de pagination dans l'application Web Java. Voici le lien:

http://www.hdpagination.org

Il peut être une option pour vous de réfléchir.

Si vous avez des questions, n'hésitez pas à demander.

1

Combien de pages de résultats les utilisateurs regardent-ils généralement? Quelle est la taille des données (total ou par enregistrement)? Cette grande liste est-elle toujours disponible (statique) ou créée par requête? Au lieu de renvoyer une page avec 25 résultats, pouvez-vous produire (par exemple) 200 dans un tableau JSON, et utiliser javascript pour afficher n .. n + 24 résultats. Si vous avez tous les résultats sur la page, vous pouvez également faire le tri là aussi. Demande un 1x1.gif? User = u1 & action = peu importe si vous voulez faire le suivi des utilisateurs (mise à jour des annonces, etc.) lors de l'affichage d'une autre page.

En fonction de votre taille de l'enregistrement, le trafic, le comportement des utilisateurs, l'envoi JSON pourrait être plus compact que le code HTML généré sur le serveur, vous obtenez

  • moins de bande passante utilisée
  • moins de requêtes faites à la serveur
  • utilisateur
  • voit mieux répondre parce que les pages sont mis à jour plus rapide (et serveur fait moins de requêtes)

mais vous aurez besoin de faire quelques anal ysis pour voir si cela va vous aider. Par exemple, si plus de la moitié des gens regardent toujours la deuxième page des résultats, vous pourriez aussi bien expédier avec les résultats de la première page 26-50. Par contre, vous ne voudriez pas envoyer 500 résultats si personne ne regarde après la page 3. À moins que vous ne vouliez gonfler vos numéros de trafic. Ou vous pourriez faire quelque chose de dynamique, comme envoyer des pages plus petites quand il y a moins de bande passante disponible. Dieu nous vivons dans les temps primitifs.