Conserver les données en session et les peupler après publication

Question

Qu'est-ce qui est préférable, garder un jeu de données en session ou le remplir à chaque postback?

Answer 1

Cela dépend de nombreux facteurs. Il est généralement préférable de ne pas conserver trop d'éléments dans la mémoire de session si votre session est inproc ou sur un serveur d'état, car elle est moins évolutive.

Si votre session réside dans la base de données, il peut être préférable de simplement actualiser à nouveau et repeupler le jeu de données, sauf si l'exécution de la requête est coûteuse.

Answer 2

N'utilisez pas la session !!! Si l'utilisateur ouvre un deuxième onglet avec une requête différente, la session sera réutilisée et les résultats ne seront pas ceux attendus. Vous pouvez utiliser une combinaison de ViewState et de Session, mais vous pouvez néanmoins mesurer le volume que vous pouvez gérer sans aucune sorte de mise en cache avant de recourir à la mise en cache.

Answer 3

Cela dépend de l'ampleur de votre travail et de l'emplacement de stockage de vos données de session sur le serveur.

Le maintien des jeux de données en session a certainement une incidence sur l'utilisation de la mémoire . Toutes les variables de session sont stockées en mémoire ou dans SQL Server si vous utilisez l'état SQL Server. Vous pouvez également décharger la charge sur une autre machine en utilisant le mode Serveur d’État.

L'aspect sérialisation / désérialisation. Si vous utilisez des ensembles de données incroyablement volumineux, les performances du serveur peuvent en souffrir.

D'autre part, avoir de très grands états de visualisation sur les pages peut être un véritable gouffre pour les performances . Je voudrais donc conserver les ensembles de données en session ou dans le cache et rechercher un "outproc". moyen de stocker ces données de session.

Answer 4

Comme je veux le moins d'opérations de base de données possible, je garderai les données en session, mais je ne suis pas sûr du meilleur moyen de le faire. Comment gérer les accès simultanés et aussi puisque les données sont partagées lorsque deux utilisateurs utilisent simultanément la page, comment puis-je m'assurer que chacun d'entre eux a son propre ensemble de données dans la session?

Answer 5

Je le garde généralement en session s'il n'est pas trop gros et / ou la base de données est lente et lente. Si les données sont volumineuses, il est généralement préférable de recharger.

Parfois, j'utilise le cache, je le charge à partir de Db pour la première fois et le place dans le cache. Au cours de la publication, je vérifie le contenu et, s’il est vide, je le recharge. Donc, le serveur gère lui-même le cache.

Answer 6

Le problème avec la session est que si elle est dans le processus, elle pourrait disparaître, ce qui n’est pas terrible, si c'est un serveur d’état, alors vous devez sérialiser et si c'est correct, vous faites quand même un aller-retour!

si le jeu de résultats est volumineux, effectuez une pagination personnalisée de manière à ne renvoyer qu'un petit sous-ensemble du total des résultats.

Si vous pensez que plusieurs utilisateurs verront cet ensemble de résultats, placez chaque page dans le cache en tant que pages utilisateur, en vous assurant que le cache est renouvelé lorsque les données sont modifiées ou après un certain temps non utilisées.

si vous ne voulez pas faire beaucoup d'allers-retours et que vous pensez avoir la mémoire, bachez tout le jeu de données dans le cache, mais faites attention à ne pas faire fondre le serveur Web.

utiliser le cache signifie que les utilisateurs n'ont pas besoin de leur propre ensemble de données mais utilisent plutôt l'ensemble global.

en ce qui concerne la simultanéité lorsque vous chargez la page d'insertion / d'édition, vous devez la renseigner avec de nouvelles données et renouveler le cache après l'ajout / la mise à jour.

Answer 7

Je suis un fervent partisan du découplage et je vois rarement, voire jamais, la nécessité d'envoyer un jeu de données complet à l'interface utilisateur.

Vous ne devriez en réalité que transmettre des objets à l'interface utilisateur qui doit être utilisée. Par conséquent, sauf si vous affichez un grand diagramme ou une sorte de structure de données devant afficher les relations entre les données, cela ne vaut pas la peine.

Les sous-ensembles de données plus petits, le cas échéant, sont beaucoup plus efficaces. Votre application utilise-t-elle réellement toutes les entités d'un jeu de données sur l'interface utilisateur? sinon, la meilleure façon de procéder serait de ne transmettre que les données que vous affichez.

Si vous liez des données à un contrôle et que vous triez / paginez dessus, vous pouvez implémenter un grand nombre d'interfaces qui permettent à l'ensemble de données de le supporter, dans un morceau de code beaucoup plus petit.

Sur cette note, je conserverais des données, qui sont en grande partie statiques (par exemple, elles ne se mettent pas à jour aussi souvent) dans le cache. Vous devez donc regarder à quelle fréquence les données sont mises à jour avant de pouvoir réellement prendre une décision.

Enfin, je le répète, je vois la nécessité d’utiliser très, très rarement un jeu de données dans l’interface utilisateur .. c’est un objet de données très lourd et les avantages financiers de l’examen de vos besoins en données, par rapport à la facilité de mise en œuvre. , pourrait dépasser de loin la nécessité de mettre en cache un ensemble de données.

IMHO, les jeux de données sont plutôt difficiles à utiliser si vous vous inquiétez des performances ou de l'utilisation de la mémoire.

Answer 8

Votre réponse ne fait pas allusion à l'utilisation des données. Est-ce des données de référence? Est-ce que l'utilisateur le met à jour activement? Plusieurs utilisateurs sont-ils censés avoir accès à la mise à jour à la fois?

Sans obtenir de meilleures informations que celles que vous avez fournies, continuez avec la sagesse généralement admise selon laquelle le fait de conserver de grandes quantités de données en session est un moyen de garantir que votre application ne sera pas mise à l'échelle et qu'elle nécessitera de lourdes ressources. une poignée de personnes.

Il existe généralement de meilleurs moyens de gérer de grands ensembles de données sans recourir au chargement de toutes les données en mémoire.

À défaut, si les besoins en données de votre application sont vraiment monstrueux, envisagez un client lourd avec un back-end de service Web. Cela conviendrait peut-être mieux que de créer une page Web.

Answer 9

Comme d'autres réponses l'ont noté, la réponse "dépend". Cependant, je suppose que vous parlez de données partagées entre utilisateurs. Dans ce cas, vous ne devriez pas stocker le jeu de données dans la session de l'utilisateur, mais le repeupler à la publication.

De plus, vous devez remplir un cache près de la couche d'accès aux données de votre application pour améliorer les performances interactives et réduire la charge sur la base de données. La conception de votre cache dépendra à nouveau du type de données (lecture seule / lecture / écriture / lecture seule).

Cette approche dissocie la session utilisateur (concept de couche d'interface utilisateur) de la gestion des données et offre l'avantage supplémentaire de prendre en charge l'utilisation partagée des données mises en cache (dans les cas où les données sont communes à plusieurs utilisateurs).

Answer 10

Ni l'un ni l'autre - ne pas "garder" n'importe quoi! Affichez uniquement ce dont un utilisateur a besoin et créez un modèle de pagination efficace pour afficher les lignes en arrière ou en arrière.

rp

Answer 11

Restez en session. Avoir l'option de repeupler si vous avez besoin, par exemple si la mémoire de la session est effacée.