Je travaille sur une application Web ASP.NET MVC 3, où j'utilise TempData pour stocker un objet de modèle, dans le scénario où l'utilisateur n'est pas connecté.
Voici le flux: < ol>
après l'étape 3, j'aurais pensé que Tempdata serait effacé?
Voici le code: J'ai trouvé cet article qui indique: Bien en le lisant avec et Le dernier me concerne un peu - puisque je fais une redirection après le poste (PRG). Mais cela ne peut pas être évité. Y a-t-il une façon de dire "abandonner cet objet". Templata.remove? Ou est-ce que je fais ça mal?
templdata ["xxx"] n'est-ce pas "lire" et ils doivent donc être étiquetés pour le retrait?
4 Réponses :
corrigé en ajoutant pas vraiment heureux à ce sujet. Je pensais que tout le point de peut aussi utiliser la session directement. templdata.remove juste après que je l'ai lu.
tempdata était que je n'a pas dois faire cela.
Ce n'est pas la façon de l'effacer. Vous pourriez avoir une session à peu près utilisée au lieu de tempdata. Un seul avantage avec les tempdata est qu'il gère les données par lui-même. Comme je l'avais répondu plus tôt, la valeur n'est effacée que lorsque l'action aboutit à 200 (tels que Viewresultsult / ContentResult) dans tous les autres scénarios, avec précision toutes les actions résultant du code d'état HTTP de 302 (telle que la redirection) conservera les données dans Templdata. Lire les informations suivantes pour plus de détails Stackoverflow.com/Questtions/32571599/...
Il y a 2 demandes HTTP impliquées ici:
Il n'y a pas de demande postale impliquée dans votre scénario. Le fait que de votre action get FOO, vous invoquez l'action post-foo ne signifie pas qu'une demande distincte est effectuée (vous êtes toujours dans le contexte de la demande initiale de GET). C'est seulement un appel de méthode C #, pas une demande séparée.
Vous stockez quelque chose dans TEMPDATA lors de la première demande et que cette tempdata sera disponible pour le second. Il sera donc disponible dans l'action du contrôleur Rendu de la page de connexion.
Vous devez donc lire de Tempdata en action Rendu à la page de connexion si vous voulez que TempData soit supprimé.
Tu as raison. Mais je m'en fiche sur la page de connexion. J'essaie de faire un "post auto" lorsqu'ils se connectent, ils n'ont donc pas à relancer le formulaire. C'est pourquoi je "appeler" mon post-action directement (je sais que ce n'est pas une demande séparée). Je suppose donc que je ne devrais pas vraiment utiliser Tempdata, car il s'agit de 2 demandes plus tard pour lesquelles j'ai besoin des données, pas la suivante.
Vous trouverez ci-dessous certains des points de clé à noter lors de l'utilisation de données TEMP.
1) Un accès en lecture aux données TEMP ne supprime pas immédiatement les éléments du dictionnaire, mais marque uniquement la suppression.
2) Les données TEMP ne supprimeront pas toujours l'élément qui a été consulté. Il ne supprime que l'élément lorsqu'une action entraîne un code d'état HTTP 200 (ViewResult / JSONRESULT / ContentResult, etc.).
3) En cas d'actions qui entraînent un HTTP 302 (telle que toutes les actions de redirection), les données sont conservées au stockage même lorsqu'il est accessible.
Se référant au numéro de point 3. Quel est le meilleur endroit pour effacer ces données TEMP lorsque je fais une redirection.
Ce n'est pas le moyen de l'effacer. Vous pourriez avoir une session à peu près utilisée au lieu de tempdata. Un seul avantage avec les tempdata est qu'il gère les données par lui-même.
Comme je l'avais répondu plus tôt, la valeur n'est effacée que lorsque l'action entraîne une 200 (telle que Viewresult / ContentResult / JSRESULT) dans tous les autres scénarios, précisément des actions résultant du code d'état HTTP de 302 (telle que la redirection) conservera les données de TempData.
lire les éléments suivants pour plus de détails
Vous devez faire une redirection complète et ne pas renvoyer une deuxième méthode d'action. C'est pourquoi ça ne marche pas.
@BuildStarted - mais la méthode postale fait faire une redirection après sa finition. Vous ne pouvez pas faire de redirection à une méthode postale, n'est-ce pas?
Eh bien, de ce que je lis sur la base des données limitées, c'est que vous faites un get and Redirection dans le code à un post - que
statefulauthorize ne sera pas appelé .@BuildStarted - Le
Statefulauthorize est appelé dans le message initial, par exemple lorsque l'utilisateur est non authentifié et essaie de soumettre le formulaire. Je ne veux pas (ni l'attendre) d'être appelé lorsque j'invoque la méthode manuellement. Quoi qu'il en soit, Darin a résumé mon problème. En bout de ligne - je ne pense pas que je devrais utiliser tempdata, je devrais utiliser la session.