Passer des valeurs d'une page aspx à une autre?

Question

Quelles sont les différentes façons de transférer des valeurs d'un code derrière une page à un autre? Les fichiers cachés peuvent-ils fonctionner sans étiquette de formulaire? J'ai 2 codes derrière les pages. Je dois transférer une valeur particulière d'une page et aller chercher dans l'autre code derrière la page. Quelle est la meilleure méthode qui peut être suivie dans cette situation? NB: Comme la taille de la chaîne à transférer est grande, nous ne pouvons pas utiliser Querystring.

Answer 1

Querystring serait le gagnant. Cependant, si c'est le code que vous essayez d'appeler d'une page à une autre, il semble que vous ayez des problèmes. Le code que vous appelez des deux pages devrait être dans une bibliothèque de classes, mais si c'est le cas, cette réponse serait très longue et certains pourraient dire que la question est trop ouverte.

Answer 2

Les champs masqués ne peuvent pas fonctionner sans étiquette de formulaire.

a) Vous pouvez afficher la page mettre la valeur particulière dans un domaine HiddenField ou du texte et le récupérer dans la page suivante par string MyVal = Request.Form["FieldName"];

b) vous pouvez envoyer la valeur par querystring. Supposons que vous redirigiez vers default2.aspx avec val = 6 par ex. Response.Redirect("default2.aspx?val=6"); et récupérer dans la page suivante par

string MyVal = Request.QueryString["val"].ToString(); 

Answer 3

Vous pouvez stocker la valeur en session. Si la concurrence est un problème, vous pouvez utiliser une clé unique (comme un guid) et passer la clé dans la chaîne de requête.

Answer 4

Première page

//create a unique key 
string guid = Guid.NewGuid().ToString(); 
//store large data in the session 
Session[guid] = BIG_VALUE_TO_TRANSFER; 
//redirect to new page, passing key as parameter 
Response.Redirect("SecondPage.aspx?guid="+guid"); 

Deuxième page

//retrieve data from session using the key in the querystring 
//you should really validate this but i can't be bothered 
BIG_TYPE bigvalue = (BIG_TYPE)Session[Request.QueryString["guid"]]; 

Answer 5

Vous pouvez utiliser l'affichage sur plusieurs pages. En utilisant cela, vous spécifiez simplement qu'une page différente doit gérer la publication, voir ce lien: http://msdn.microsoft.com/en-us/library/ms178139.aspx

Je ne recommande généralement pas l'utilisation de variables de session, car elles réduisent l'évolutivité de l'application, et elles ne fonctionnent pas bien. avec capitonné du navigateur

modifier: Une autre option pourrait être de stocker les données dans le HttpContext actuel puis utilisez Server.Transfer

HttpContext.Current.Items["tempData"] = yourLongData; 
Server.Transfer("NewPage.aspx"); 

sur la nouvelle page, vous pouvez lire la valeur de la HttpContext . Cela fonctionnerait car la nouvelle page est traitée dans la même requête, et donc dans le même contexte.

Mais cela ne provoque pas de redirection du client, donc il ne peut pas être applicable dans tous les cas

Answer 6

Pour transférer le contrôle d'une page à une autre, vous pouvez utiliser

Server.Transfer ("newpage.aspx"); 

Méthode

et pour la valeur passant d'une page à une autre, vous pouvez utiliser le contexte

Context.Items["Value1"] = "value to pass"; 

et récupérer la valeur dans la page cible

string val = Context.Items["Value1"].ToString(); // check for null 

La longueur maximale de querystring sera différent dans les différents navigateurs. De plus, la transmission d'informations sensibles via une chaîne querys n'est pas une bonne approche.

Response.Redirect implique un aller-retour au serveur alors que Server.Transfer conserve les ressources du serveur en évitant l'aller-retour. Il modifie simplement le focus du serveur Web sur une autre page et transfère le traitement de la page vers une autre page.

Si vous utilisez Server.Transfer alors vous pouvez accéder directement aux valeurs, contrôles et propriétés de la page précédente que vous ne pouvez pas faire avec Response.Redirect. Response.Redirect modifie l'URL dans la barre d'adresse du navigateur. Donc, ils peuvent être marqués . Alors que Server.Transfer conserve l'URL d'origine dans la barre d'adresse du navigateur . Il remplace le contenu de la page précédente par la nouvelle page .

Response.Redirect peut être utilisé aussi bien pour les .aspx et pages html alors que Server.Transfer peut être utilisé que pour .aspx pages et est spécifique à ASP et ASP.NET . Response.Redirect peut être utilisé pour rediriger un utilisateur vers un site Web externe . Server.Transfer peut être utilisé uniquement sur les sites fonctionnant sur le même serveur . Vous ne pouvez pas utiliser Server.Transfer pour rediriger l'utilisateur vers une page exécutant sur un serveur différent.

Answer 7

Utilisez session qui faire le travail pour vous, mais depuis la session doit contenir des données de session spécifique, vous devez l'utiliser correctement, vous pouvez également utiliser Server.Transfer

Answer 8

Pour morceaux vraiment grandes quantités de données, il n'y a aucun moyen vous voulez envoyer toutes ces données au client juste pour revenir tout de suite. C'est effectivement ce que vous faites quand vous mettez une valeur comme un champ de formulaire ou une chaîne de requête. Vous allez utiliser la bande passante et ralentir l'expérience de vos utilisateurs.

Le stockage d'énormes quantités de données dans la session est une très mauvaise idée . C'est soit in-proc qui utilise la mémoire principale de votre serveur, soit il est sérialisé vers un autre serveur (State Server), soit stocké dans une base de données (Sql State). Les données de session sont récupérées pour chaque requête. C'est un tueur de performance total .

Si vous avez vraiment besoin de transmettre autant de données d'une page à l'autre, évaluez vos besoins de cohérence. Si c'est vraiment transactionnel, vous avez peut-être besoin de mordre la balle et de stocker dans une base de données. L'autre page peut récupérer si nécessaire.

La plupart des bases de données peuvent (effectivement) stocker n'importe quelle quantité de données que vous leur lancez, mais n'abusez pas de la base de données si vous n'avez pas besoin de la cohérence d'une base de données. Hors du sommet de ma tête, j'irais pour environ 8k de données. Je reconnais varchar (max), etc, mais vous devez évaluer le compromis de stockage de toutes les données (transitoires), l'espace de journal, etc.

Sinon, il n'y a rien de mal à créer un fichier temporaire sur un disque réseau partagé et passer un jeton autour. Utilisez un guid et la date pour générer un nom de fichier unique.