Meilleures pratiques pour la transmission de données entre pages

Question

Le Problème

Dans la pile de nous ré-utiliser entre les projets, nous avons mis un peu trop de données dans la session de la transmission des données entre les pages. C'était bon, en théorie, parce qu'elle empêche l'altération, les attaques de relecture, et ainsi de suite, mais il crée autant de problèmes qu'elle n'en résout.

Perte de Session elle-même est un problème, même si c'est principalement gérée par la mise en œuvre de l'État de Session du Serveur (ou à l'aide de SQL Server). Plus important encore, il est difficile de faire le dos bouton de fonctionner correctement, et c'est aussi un travail supplémentaire pour créer une situation où un utilisateur peut par exemple ouvrir le même écran en trois onglets à travailler sur différents dossiers.

Et ce n'est que la partie émergée de l'iceberg.

Il existe des solutions de contournement pour la plupart de ces questions, mais comme je l'ai moudre loin, tout ce frottement me donne le sentiment que la transmission des données entre les pages à l'aide de session est la mauvaise direction.

Ce que je veux vraiment faire est de venir avec une meilleure pratique qui ma boutique pouvez utiliser tout le temps de la transmission des données entre les pages, et puis, pour de nouvelles applications, de remplacer des éléments clés de notre pile qui dépendent actuellement de la Session.

Il serait bien aussi si la solution finale n'a pas de suite dans les montagnes de réutilisable code de plomberie.

Les Solutions Proposées

Session

Comme mentionné ci-dessus, s'appuyant sur la Session semble comme une bonne idée, mais il casse le bouton de retour et cause d'autres problèmes.

Il peut y avoir des façons de contourner tous les problèmes, mais il semble que beaucoup de travail supplémentaire.

Une chose qui est très agréable sur l'utilisation de la session est le fait que l'altération n'est tout simplement pas un problème. Par rapport au passage de tout par en clair de la chaîne de recherche, vous finissez par écrire beaucoup moins de la garde de code.

La Croix-L'Affichage De La Page

En vérité, j'ai à peine songé à cette option. J'ai un problème avec la façon dont étroitement couplée il rend les pages -- si je me mets à faire PreviousPage.FindControl("SomeTextBox"), cela ressemble à un problème de maintenance si jamais je veux accéder à cette page à partir d'une autre page qui peut-être ne pas avoir un contrôle appelé SomeTextBox.

Il semble limitée par d'autres moyens également. Peut-être que je veux accéder à la page via un lien, par exemple.

QueryString

Je suis actuellement en penchant vers cette stratégie, comme dans les temps anciens. Mais j'ai probablement voulez mon QueryString être cryptés afin de le rendre plus difficile à falsifier, et je voudrais traiter le problème des attaques de relecture.

Sur les 4 gars de Rolla, il y a un article à ce sujet.

Cependant, il devrait être possible de créer un HttpModule qui prend soin de tout cela et supprime tout le chiffrement de saucisses à partir de la page. Bien sûr, Mad Kristenson a un article où il sort. Cependant, les commentaires de la faire sonner comme il a des problèmes avec extrêmement de scénarios communs.

D'Autres Options

Bien sûr, ce n'est pas exaustive de voir les options, mais plutôt les principales options je suis en train d'étudier. Ce lien contient une liste plus complète. Ceux que je n'ai pas mentionné tels que les Cookies et le Cache n'est pas approprié pour le but de la transmission des données entre les pages.

En Guise De Conclusion...

Alors, comment gérez-vous le problème de la transmission des données entre les pages? Quels pièges cachés avez-vous avoir à contourner, et il y a des pré-existante outils autour de ce que tous les résoudre parfaitement? Ne vous sentez que vous avez une solution que vous êtes complètement satisfait?

Merci à l'avance!

Mise à jour: Juste au cas où je suis de ne pas être assez clair, par "le passage des données entre les pages de" je suis en train de parler, par exemple, le passage d'un code client clé à partir d'un CustomerSearch.page aspx aux Clients.aspx, où le Client sera ouvert et l'édition peut se produire.

Answer 1

D'abord, les problèmes auxquels vous êtes confronté liés à la manipulation de l'état dans un état moins l'environnement. Les difficultés que vous rencontrez ne sont pas nouvelles, et c'est probablement l'une des choses qui rend développement web plus difficile que de développement de windows ou le développement d'un exécutable.

Avec le respect du développement web, vous avez le choix entre cinq options, pour autant que je suis au courant, pour le traitement spécifique de l'utilisateur de l'état, qui peuvent tous être utilisés en combinaison les uns avec les autres. Vous constaterez que pas de solution qui fonctionne pour tout. Au lieu de cela, vous avez besoin de déterminer quand utiliser chaque solution:

• Chaîne de requête - Requête chaînes sont bon pour passer des pointeurs vers les données (par exemple des valeurs de clé primaire) ou des valeurs d'état. Les chaînes de requête par eux-mêmes ne doit pas être supposé pour être sûr, même si elle est cryptée en raison de la relecture. En outre, certains navigateurs ont une limite sur la longueur de l'url. Toutefois, les chaînes de requête ont certains avantages, tels qu'ils peuvent être mis en signet et envoyé par courriel aux personnes et sont par nature sans état si ce n'est pas avec autre chose.

• Cookies: les Cookies sont bons pour le stockage de très petites quantités de l'information pour un utilisateur particulier. Le problème est que les témoins ont aussi une limitation de la taille, après quoi il sera tout simplement tronquer les données de sorte que vous devez être prudent de mettre des données personnalisées dans un cookie. En outre, les utilisateurs peuvent tuer les cookies ou d'empêcher leur utilisation (bien que ce serait empêcher l'utilisation de la norme de la Session). Semblables à des chaînes de requête, les cookies sont de mieux, de l'OMI, des pointeurs vers les données que pour les données lui-même, sauf si les données sont minuscules.

• Les données de formulaire - Formulaire de données peut prendre un peu de renseignements au prix toutefois de poste temps et, dans certains cas, le temps de rechargement. ASP.NET's ViewState utilise caché variables de formulaire pour conserver les informations. Le passage des données entre les pages à l'aide de quelque chose comme l'état d'affichage a l'avantage de travailler plus agréable avec le bouton de retour, mais on peut facilement créer ginormous pages qui ralentissent l'expérience de l'utilisateur. En général, ASP.NET le modèle ne fonctionne pas sur la page de validation (bien qu'il soit possible), mais s'appuie plutôt sur des postes à la même page et à partir de là, la navigation à la page suivante.

• Session - Session est bon pour l'information qui se rapporte à un procédé avec lequel l'utilisateur est de progresser ou pour les paramètres généraux. Vous pouvez stocker un bit d'information dans la session sur le coût de la mémoire du serveur ou les temps de chargement à partir de la bases de données. Sur le plan conceptuel, Séance de travaux par le chargement de l'ensemble de la liasse de données pour l'utilisateur, tout à la fois, soit à partir de la mémoire ou à partir d'un serveur d'état. Cela signifie que si vous disposez d'un très large ensemble de données que vous ne voulez probablement pas à le mettre dans la session. Session peut créer certains des problèmes de bouton de retour qui doit être pesé à l'encontre de ce que l'utilisateur est en train d'essayer d'accomplir. En général, vous constaterez que le bouton de retour peut être un fléau pour le développeur web.

• Base de données - La dernière solution (qui peut aussi être utilisé en combinaison avec d'autres), c'est que vous stocker les informations dans la base de données dans son schéma, avec une colonne qui indique l'état de l'élément. Par exemple, si vous avez été la manipulation de la création d'une commande, vous pouvez stocker la commande dans l'Ordre de la table avec une colonne "etat" qui détermine si c'était un ordre réel ou pas. Vous serait de stocker l'identificateur de commande dans la chaîne de requête ou de la session. Le site web continuera à écrire des données dans la table à mettre à jour les différentes parties et les éléments enfants, jusqu'à ce que finalement l'utilisateur est en mesure de déclarer qu'ils sont fait et l'ordre de l'état est marquée comme étant un ordre réel. Ce qui peut compliquer les rapports et les requêtes qu'ils ont tous besoin de différencier les "vrais" des articles de ceux qui sont dans le processus.

L'un des éléments mentionnés dans votre plus tard, le lien a été le Cache de l'Application. Je ne considère pas que cela soit spécifique à l'utilisateur puisque c'est l'application de large. (Il peut évidemment être chaussure cornes en étant spécifique à l'utilisateur, mais je ne recommande pas que ce soit). Je n'ai jamais joué avec l'enregistrement des données dans le HttpContext à l'extérieur de la transmettre à un gestionnaire ou d'un module, mais je serais sceptique que c'était toute différente de celle que les solutions mentionnées ci-dessus.

En général, il n'y a pas de solution unique pour les gouverner tous. La meilleure approche est de supposer sur chaque page que l'utilisateur pourrait avoir accédé à cette page à partir de n'importe où (par opposition à supposer qu'ils arrivés là à l'aide d'un lien sur une autre page). Si vous le faites, bouton de retour, les questions deviennent plus faciles à gérer (bien que toujours une douleur). Dans mon développement, j'utilise les quatre premiers de manière approfondie et à l'occasion de recourir à la dernière solution quand la nécessité l'exige.

Answer 2

Bon, alors je veux commencer ma réponse avec ce; Thomas a clairement la plus précise et la réponse complète à ce jour pour les gens de commencer à neuf. Cette réponse n'est pas dans la même veine. Ma réponse est à venir à partir d'un "business developer" point de vue. Comme nous le savons tous trop bien, mais parfois c'est juste pas possible de dépenser de l'argent ré-écrire quelque chose qui existe déjà et qui "fonctionne"... au moins pas tout d'un seul coup. Parfois, il est préférable de mettre en œuvre une solution qui va vous permettre de migrer vers une meilleure alternative au fil du temps.

La seule chose que je dirais que Thomas est absent; javascript côté client de l'état. Où je travaille, nous avons trouvé des clients viennent à s'attendre à "Web 2.0"les applications de type plus et plus. Nous avons également trouvé que ces sortes d'applications en général beaucoup plus élevé de satisfaction de l'utilisateur. Avec un peu de pratique, et l'aide de quelques très grandes bibliothèques javascript comme jQuery (nous avons même commencé à utiliser GWT et l'a trouvé pour être IMPRESSIONNANT) de communiquer avec JSON REST services mis en œuvre dans WCF peuvent être trivial. Cette approche est aussi une très belle façon de commencer à se déplacer vers une SOA architecture, et de la séparation de l'INTERFACE utilisateur et la logique métier.

Mais je m'égare.

Il me semble que si vous avez déjà une application, et vous avez déjà mis à rude épreuve les limites de ASP.NET's intégrée de gestion d'état de session. Alors... voici ma suggestion (en supposant que vous avez déjà essayé ASP.NET s'out-of-process de gestion de session, où les échelles signifigantly mieux que les processus de gestion de session, et il semble que vous avez parce que vous avez mentionné qu'il); NCache.

NCache vous fournit avec un "drop-in" de remplacement pour ASP.NET s'session options de gestion. Il est super facile à mettre en œuvre et pourrait "band-aid" de votre application plus que bien assez pour passer à travers sans investissement significatif dans la refactorisation de votre base de code existante immédiatement.

Vous pouvez utiliser le surplus de temps et d'argent pour commencer à réduire votre dette technique en se concentrant de nouveau développement sur les choses avec immédiats de valeur à l'aide d'une nouvelle approche (comme les solutions de rechange offertes dans les autres réponses, ou de la mienne).

Juste mes pensées.

Answer 3

Plusieurs mois plus tard, j'ai pensé que je voudrais mettre à jour cette question avec la technique que j'ai fini par aller avec, car il a travaillé très bien.

Après avoir joué avec les plus impliqués gestion des états de session (qui a entraîné beaucoup de débris de boutons de retour et ainsi de suite) j'ai fini par rouler mon propre code pour gérer chiffré QueryStrings. Il a été une grande victoire -- tous mes scénarios de problème (bouton de retour, plusieurs onglets ouverts en même temps, la perte de l'état de session, etc) sont résolus et de la complexité est minime, car l'utilisation est très familier.

Ce n'est pas une formule magique pour tout, mais je pense que c'est bon pour environ 90% des scénarios de vous rencontrer.

Détails

J'ai construit une classe appelée CorePage qui hérite de la Page. Il a des méthodes appelé SecureRequest et SecureRedirect.

De sorte que l'on pourrait appeler:

 SecureRedirect(String.Format("Orders.aspx?ClientID={0}&OrderID={1}, ClientID, OrderID)

CorePage analyse de la chaîne de Requête et les encode dans une QueryString variable appelée CoreSecure. De sorte que la demande réelle ressemble à ceci:

Les ordres.aspx?CoreSecure=1IHXaPzUCYrdmWPkkkuThEes%2fIs4l6grKaznFGAeDDI%3d

Si disponible, vous êtes déjà connecté au code d'utilisateur est ajouté à la clé de chiffrement, de sorte que les attaques de relecture ne sont pas aussi beaucoup d'un problème.

À partir de là, vous pouvez appeler:

X = SecureRequest("ClientID")

Conclusion

Tout fonctionne de manière transparente, en utilisant la syntaxe familière.

Au cours des derniers mois, j'ai également adapté ce code pour travailler avec les cas limites, tels que les liens hypertexte que déclencher un téléchargement - parfois, vous avez besoin de générer un lien hypertexte sur le client qui a une chaîne de Requête. Qui fonctionne vraiment bien.

Laissez-moi savoir si vous voulez voir ce code et je vais le mettre quelque part.

Une dernière pensée: c'est bizarre d'accepter ma propre réponse sur quelques-uns des très réfléchie posts d'autres personnes sur le web, mais cela ne semble vraiment être l'ultime réponse à mon problème. Merci à tous ceux qui ont aidé à me rendre là.

Answer 4

Je ne ferais jamais ça. Je n'ai jamais eu de problème pour stocker toutes les données de session dans la base de données, pour la charger en fonction du cookie de l'utilisateur. C'est une session en ce qui concerne n'importe quoi, mais je garde le contrôle sur elle. N'abandonnez pas le contrôle de vos données de session sur votre serveur Web ...

Avec un peu de travail, vous pouvez prendre en charge des sous-sessions et autoriser le multitâche dans différents onglets / fenêtres.

Answer 5

En tant que point de départ, je trouve l'aide de la critique des éléments de données, comme un numéro de Client, de mieux le mettre dans la chaîne de requête pour le traitement. Vous pouvez suivre facilement/filtre de mauvaises données provenant de ces éléments, et il permet également l'intégration avec e-mail ou d'autres sites/applications.

Dans une demande précédente, le seul moyen pour afficher un employé ou d'une demande d'enregistrement impliquant était pour vous connecter à l'application, de faire une recherche pour l'employé ou de faire une recherche pour les récents records pour trouver le dossier en question. Cela devenait problématique et un grand puits de temps quand quelqu'un à partir d'un département a dû faire un simple point de vue sur des dossiers à des fins de vérification.

Dans la réécriture, j'ai fait à la fois l'Id de l'employé, et à la demande de l'Id sont disponibles via une URL de base de "ViewEmployee.aspx?Id=XXX" et "ViewRequest.aspx?Id=XXX". L'application a été l'installation d'Un filtre mauvais Id et B) d'authentifier et d'autoriser l'utilisateur avant de les autoriser à ces pages. Ce que cela a permis à l', principalement les utilisateurs de l'application à faire était d'envoyer des e-mails simples pour les auditeurs avec une URL dans l'e-mail. Quand ils étaient dans une grande hâte, ils étaient dans leur masse de temps de traitement, ils ont été en mesure de simplement cliquer sur une liste d'Url et de faire le traitement approprié.

Session d'autres données connexes, telles que les dates de modification et le maintien de "l'état" de l'utilisateur de l'interaction avec l'application devient un peu plus complexe, mais j'espère que ce départ poing pour vous.