Combien de données pouvez-vous / devriez-vous stocker dans un objet de session utilisateur?

Question

Notre site Web contient plusieurs applications de formulaire de type assistant, dans lesquelles nous capturons les informations de l'utilisateur sur chaque page, puis nous les soumettons à un processus backend à l'aide d'un service Web.

Malheureusement, nous ne pouvons pas soumettre les informations par morceaux lors de chaque soumission de formulaire. Nous devons donc la stocker dans la session des utilisateurs jusqu'à la fin du processus et la soumettre en même temps.

Est-ce que la quantité de mémoire serveur / espace disque du serveur SQL est la seule contrainte sur le montant que je peux stocker dans les sessions des utilisateurs ou y a-t-il autre chose que je devrais prendre en compte?

Modifier: le site est construit sur des formulaires Web ASP.NET.

Answer 1

En supposant que les informations ne soient pas sensibles, vous pouvez les stocker dans un cookie, ce qui réduirait la quantité d'informations devant être stockées côté serveur. Cela vous permettrait également d'accéder aux informations via JavaScript.

Vous pouvez également utiliser viewstate pour stocker les informations, même si cela peut entraîner l'envoi de grandes quantités de données entre le serveur et le client, et non la solution que je préfère.

La quantité d'informations de session que vous devez stocker varie énormément en fonction de l'application, du nombre d'utilisateurs attendus, de la spécification du serveur, etc. Pour obtenir une réponse plus précise, des informations complémentaires seraient nécessaires:)

Enfin, en supposant que les informations collectées tout au long du processus ne soient pas requises de page en page, vous pouvez stocker toutes les informations dans une table de base de données et ne stocker que l'ID unique des enregistrements dans la session. Au fur et à mesure que chaque page est soumise, l'enregistrement de la base de données est mis à jour, puis sur la dernière page, toutes les informations sont récupérées et soumises. Ce n’est pas une solution idéale si vous devez récupérer les informations précédentes sur chaque page suivante en raison du nombre de lectures de base de données requises.

Answer 2

Vous pouvez également disposer d'une page asp avec l'intégralité du formulaire html et en masquer des parties jusqu'à ce que l'utilisateur remplisse et "soumette". la partie visible ...

masquez simplement la partie remplie et affichez la partie suivante du formulaire ...

Cela serait extrêmement facile dans le framework .NET, utilisez des panneaux pour chaque "étape de l'assistant". et ajoutez le moment où afficher et masquer chaque panneau.

vous aurez alors toutes les données sur une page.

Answer 3

Si vous utilisez un modèle HTTP traditionnel (par exemple, n'utilisez pas runat = "serveur"), vous pouvez publier les données sur une autre page asp et les placer dans des éléments de formulaire masqués. Vous pouvez le faire, quel que soit le nombre de pages. vous devez donc éviter de placer quoi que ce soit dans une variable de session.

Answer 4

Comme il est problématique, du point de vue des performances, de stocker de grandes quantités de données dans l’objet Session utilisateur, ASP.Net propose d’autres solutions de contournement par rapport à ce qui est mentionné dans les publications ci-dessus. Le fournisseur de profil ASP.NET permet de conserver les informations relatives à la session dans un base de données. Vous pouvez également utiliser le serveur d'état de session qui stocke un serveur distinct toutes les informations de la session. Si vous devez utiliser des grappes ou des équilibreurs de charge, ces deux situations sont prises en compte. Les serveurs peuvent toujours reconnaître les informations de session sur différents serveurs. Si vous stockez des informations dans l'objet Session HTTP, vous rencontrez le problème suivant: un utilisateur doit toujours accéder au même serveur pour cette session.

Answer 5

Session, état de la vue, base de données. Ils sont tous lents mais feront le travail.

Les champs de formulaire masqués sont la réponse qui me convient le mieux.

Il existe d'autres moyens de conserver l'état. Cookies, fenêtres popup, cadres ou iframes.