ASP.NET MVC - TempData - Bonne ou mauvaise pratique

96

J'utilise la AcceptVerbsméthode détaillée dans l'article de blog Aperçu 5 de Scott Gu pour traiter les entrées de formulaire dans ASP.NET MVC:

L'utilisateur reçoit un formulaire vide via GET
L'utilisateur publie le formulaire rempli via POST à la même action
L'action valide les données, prend les mesures appropriées et redirige vers une nouvelle vue

Donc je n'ai pas à utiliser TempData. Cela dit, je dois maintenant ajouter une étape de «confirmation» à ce processus, et cela semble nécessiter l'utilisation de TempData.

Pour une raison quelconque, j'ai une aversion pour l'utilisation TempData- que c'est quelque chose qui doit être conçu.

Est-ce vraiment une préoccupation valable ou est-ce que je l'invente?

asp.net-mvc tempdata

— anonyme
source

1

Pensez à faire de votre étape de «confirmation» une boîte de dialogue javascript. Moins d'allers-retours serveur et vous ne rencontrerez pas ce problème.

— ajma

26

Je pense en quelque sorte aux données temporaires comme étant un mécanisme à feu et à oublier pour avertir l'utilisateur. C'est génial de leur rappeler quelque chose qu'ils ont fait récemment, mais j'hésiterais également à en faire une étape obligatoire dans certains processus utilisateur. La raison étant que s'ils actualisent la page, je pense qu'elle disparaîtrait. Eh bien, je suppose que j'hésite aussi à l'utiliser car il n'est pas vraiment bien défini à quel point il est fiable.

Je me demande si le problème est que l'action est redirigée vers une autre page avant l'étape de confirmation. Je me demande si à la place, après leur première soumission, vous pourriez faire suffisamment de traitement pour générer la boîte de dialogue de confirmation, puis renvoyer la page d'origine avec la question de confirmation. Similaire à la façon dont vous pouvez effectuer la validation, sauf que la règle de validation vérifie si l'étape de confirmation a été effectuée (avec l'interface utilisateur de confirmation masquée jusqu'à ce que les autres validations réussissent).

— Frank Schwieterman
source

77

Pas besoin d'avoir une aversion pour TempData ... Mais s'il n'est pas utilisé correctement, cela pourrait sûrement être une indication d'une mauvaise conception. Si vous utilisez des URL RESTful, TempData est une meilleure pratique pour transférer les messages de vos actions POST vers vos actions GET. Considère ceci:

Vous avez un formulaire sur URL Products / New. Le formulaire Posts to Products / Create, qui valide le formulaire et crée le produit, en cas de succès, le contrôleur redirige vers l'URL Products / 1 et en cas d'erreur, il redirige vers les produits / Nouveau pour afficher les messages d'erreur.

Produits / 1 n'est que l'action GET standard pour le produit, mais nous aimerions qu'un message s'affiche indiquant que l'insertion a réussi. TempData est parfait pour cela. Ajoutez le message à TempData dans le contrôleur de poste et mettez-en une logique dans la vue et c'est fait.

En cas d'échec, j'ai ajouté les valeurs entrées dans formCollection et une collection de messages d'erreur à TempData dans la post-action, et je suis redirigé vers l'action initiale Prodcuts / New. J'ai ajouté une logique à la vue pour remplir les entrées du formulaire avec les valeurs précédemment entrées avec tous les messages d'erreur. Cela me semble beau et propre!

— JasonD
source

Pourquoi faire ce travail supplémentaire lorsque vous pouvez publier directement sur Products/New? Quelle valeur Products/Createajoute-t-il?

— mpen

2

@Mark, l'utilisation de Produits / Créer empêche la situation où l'utilisateur termine l'action via la publication, puis, lors d'une actualisation ultérieure (ou d'un signet et d'un retour), recomplète accidentellement l'action. Pour plus d'informations, voir en.wikipedia.org/wiki/Post/Redirect/Get

— ehdv

2

@ehdv: Mais est-ce vraiment? En cas de succès, il redirige vers une autre page, en cas d'échec, il doit afficher les erreurs de formulaire et aucune action ne doit être entreprise, donc aucun mal n'est fait. Cela empêcherait seulement ce message ennuyeux "êtes-vous sûr de vouloir re-poster", ce que je veux souvent faire. Je suppose que cela dépend de votre conception, donc je peux voir votre point.

— mpen

31

Je pense que vous feriez bien d'hésiter avant d'utiliser TempData. TempData est stocké dans la session et cela peut avoir des implications pour vous si:

Vous n'utilisez pas de sessions sur votre site pour le moment
Vous avez un système qui doit évoluer vers un débit élevé, c'est-à-dire que vous préférez éviter complètement l'état de session
Vous ne voulez pas utiliser de cookies (je ne sais pas dans quelle mesure MVC prend en charge les sessions sans cookie pour le moment)

Si votre site doit avoir une haute disponibilité, il existe des considérations supplémentaires concernant l'application de l'état de session, mais ce sont tous des problèmes résolus.

— John Rayner
source

16

TempData n'a pas besoin d'être stocké en session, bien qu'il s'agisse du fournisseur par défaut - ce qui explique probablement pourquoi il n'est pas dans la méthode doc. Il existe également un fournisseur de cookies, pour illustrer comment écrire un fournisseur personnalisé.

— FinnNk

3

J'ai une méthode GetModel qui vérifie d'abord TempData ["modèle"] et le renvoie. Sinon, GetModel charge les données appropriées à partir de la base de données.

Cela économise une charge supplémentaire de la base de données lorsque j'ai une action qui doit renvoyer une vue différente qui nécessite les mêmes données de modèle.

— Todd Smith
source

Yah, j'ai rencontré ceci: (1) valider un enregistrement existe, s'il est valide, rediriger vers l'enregistrement de chargement de la page (2) à afficher pour l'utilisateur. Ainsi, la base de données est frappée pour la validation et pour l'affichage. J'utilise presque TempData pour cela, mais j'avais envie de vérifier les opinions. J'aime bien votre méthode pour la contenir.

— anonyme

Il serait préférable d'utiliser un mécanisme de mise en cache approprié dans ce scénario.

— nicodemus13

3

Découvrez les contrôleurs sans session dans MVC3. Il s'est avéré que l'utilisation de session empêche l'exécution parallèle des demandes d'un seul utilisateur et conduit ainsi à une dégradation des performances.

Puisque tempdata utilise la session par défaut, vous ne pourrez pas utiliser cette fonctionnalité. Vous pouvez passer à l'utilisation de cookies pour les données temporaires, mais c'est un peu gênant (du moins pour moi). Encore plus propre que viewstate, alors peut-être que ce n'est pas un si gros problème.

— aaimnr
source

2

Vous avez raison sur les contrôleurs sans session et TempData utilise la session. MAIS ATTENDEZ! La session n'est PAS une mauvaise chose et vous pouvez mélanger et associer Sessionless avec des contrôleurs de session. Vous voulez vraiment des contrôleurs Session_less_ lorsque vous effectuez de nombreux appels AJAX vers le serveur (depuis le navigateur). Lorsque vous venez de frapper une page -à-la-fois- .. vous n'avez pas besoin d'être sans session. En fait, cela ne devrait PAS vous donner aucun avantage ... parce que vous ne touchez le serveur qu'une fois. Il est donc possible de mélanger et d'assortir.

— Pure.Krome

2

Pourquoi avez-vous une telle aversion? Cette chose est simplement faire son travail et le faire bien :)

Si vous ne l'aimez pas à cause de son caractère non fortement typé, vous pouvez toujours créer un wrapper qui vous fournira une interface fortement typée.

— maxnk
source

2

C'est comme utiliser ViewData, ce qui signifie que ce n'est probablement pas un risque pour la sécurité. Mais je préfère utiliser ViewData que TempData. Vérifiez ici pour une comparaison: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

En fonction de la conception, vous pouvez toujours stocker l'utilisateur / le panier ou ce dont vous avez besoin dans les données temporaires de la base de données et avoir juste un champ "IsReady" qui indique s'il est terminé ou non, ce qui le rend extensible pour plus tard si vous souhaitez prendre en charge l'esprit, que les gens peuvent fermer leur navigateur.

— Filip Ekberg
source

2

Remarque: l'article auquel vous créez un lien était à jour pour son heure, mais n'est précis que pour MVC1. TempData a changé de manière assez significative dans MVC2.

— mikemanne

@mikemanne, ouais. Mais la réponse date de fin 2008. Mais peut-être que la réponse devrait être mise à jour?

— Filip Ekberg

0

Toutes les bonnes réponses, avez-vous jeté un coup d'œil à ceci pour faire passer des messages.

TempData et Session ne sont pas la meilleure idée pour les architectures RESTful car la plupart des sessions sont stockées en mémoire. Ainsi, lorsque vous souhaitez utiliser une batterie de serveurs, la session des utilisateurs existe sur un serveur tandis que leur demande suivante peut être envoyée à un autre serveur.

Cela étant dit, jetez un œil à cette utilisation de TempData pour passer des messages ici.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mabye cela pourrait être adapté pour utiliser une approche de chaîne de requête si utilisé uniquement pour la redirection vers une autre page d'alertes.

— Garenne
source