ASP.NET MVC - TempData - Bonne ou mauvaise pratique
J'utilise la méthode AcceptVerbs détaillée dans l'article de blog Preview 5 de Scott Gu pour traiter les entrées de formulaire dans ASP.NET MVC:
- L'utilisateur obtient un formulaire vide via GET
- L'utilisateur poste le formulaire rempli via POST sur 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, qui semble nécessiter l’utilisation de TempData.
Pour une raison quelconque, j’ai une aversion pour l’utilisation de TempData - que c’est quelque chose qui doit être conçu autour.
Est-ce une préoccupation valable ou est-ce que je l'invente?
Je pense en quelque sorte que les données temporaires sont un mécanisme incessant de notification destiné à l'utilisateur. C'est formidable de leur rappeler quelque chose qu'ils ont fait récemment, mais j'hésiterais également à en faire une étape obligatoire du processus utilisateur. La raison en est que si ils rafraîchissent la page, je crois que ce serait parti. Eh bien, j’imagine que j’hésite également à l’utiliser, car sa fiabilité n’est pas vraiment définie.
Je me demande si le problème vient du fait que l'action est redirigée vers une autre page avant l'étape de confirmation. Je me demande si, après leur première soumission, vous pourriez effectuer 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. Semblable à la procédure de validation, la règle de validation vérifie si l'étape de confirmation a été effectuée (l'interface utilisateur de confirmation étant masquée jusqu'à ce qu'une autre validation réussisse).
Pas besoin d'avoir une aversion pour TempData ... Mais s'il n'est pas utilisé correctement, cela pourrait sûrement indiquer une mauvaise conception. Si vous utilisez des URL RESTful, TempData constitue une pratique recommandée pour transférer des messages de vos actions POST vers vos actions GET. Considère ceci:
Vous avez un formulaire sur URL Products/New. Le formulaire Postes dans 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, les produits/Nouveau pour afficher les messages d'erreur.
Products/1 est simplement l'action standard de GET pour le produit, mais nous souhaiterions qu'un message s'affiche pour indiquer que l'insertion a été un succès. TempData est parfait pour cela. Ajoutez le message à TempData dans le post-contrôleur et mettez-y de la logique si dans la vue et c'est terminé.
En cas d'échec, j'ai ajouté les valeurs entrées dans formCollection et une collection de messages d'erreur à TempData dans l'action post, puis redirigé vers l'action initiale Prodcuts/New . J'ai ajouté une logique à la vue pour renseigner la entrées de formulaire avec les valeurs entrées précédemment avec tous les messages d'erreur. Semble gentil et propre pour moi!
Je pense que vous avez tout intérêt à hésiter avant d'utiliser TempData. TempData est stocké dans la session et cela peut avoir des conséquences pour vous si:
- Vous n'utilisez pas de sessions sur votre site pour l'instant
- 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 actuellement en charge les sessions sans cookies)
Si votre site doit disposer d'une haute disponibilité, vous devez prendre en compte d'autres considérations relatives à l'application de l'état de session, mais vous devez résoudre ces problèmes.
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 évite une charge supplémentaire de la base de données lorsque une action doit renvoyer une vue différente nécessitant les mêmes données de modèle.
Vérifier les contrôleurs sans session dans MVC3. Il s'est avéré que l'utilisation de session empêche l'exécution en parallèle des requêtes d'un seul utilisateur et entraîne donc une dégradation des performances.
Puisque tempdata utilise session par défaut, vous ne pourrez pas utiliser cette fonctionnalité. Vous pouvez utiliser des cookies pour tempdata, mais c'est un peu gênant (du moins pour moi). Toujours plus propre que viewstate, cependant, peut-être que ce n'est pas un gros problème.
C'est comme utiliser ViewData, ce qui signifie que ce n'est probablement pas un risque de sécurité. Mais je préférerais utiliser ViewData que TempData. Cliquez ici pour une comparaison: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/
Selon la conception, vous pouvez toujours stocker l'utilisateur/le panier ou ce dont vous avez besoin dans la base de données tempdata et simplement avoir un champ "IsReady" qui indique s'il est terminé ou non, le rendant extensible pour plus tard si vous souhaitez en prendre l'esprit, que les gens peuvent fermer leurs navigateurs.
Pourquoi as-tu une telle aversion? Cette chose est simplement faire son travail et bien le faire :)
Si vous ne l'aimez pas à cause de son caractère non fortement typé, vous pouvez toujours créer une enveloppe qui fournira une interface fortement typée.
Toutes les bonnes réponses, avez-vous jeté un coup d'œil à cela 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 alors que leur demande suivante peut être envoyée à un autre serveur.
Cela dit, jetez un coup d’œil à cette utilisation de TempData pour la transmission de messages ici.
http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/
Mabye pourrait être adapté pour utiliser une approche de chaîne de requête s'il est utilisé uniquement pour la redirection vers une autre alerte de page.