J'utilise le Rediriger après la poste modèle dans mon asp.net mvc application. j'ai Le scénario suivant:
/ contrôleur / index où il est demandé de remplir un formulaire.
- Les valeurs de formulaire sont affichées sur
/ Controller / Calculez .
- Le
Calculez Action effectue un calcul basé sur l'entrée et instancie d'un objet complexe contenant les résultats de l'opération. Cet objet est stocké dans tempdata et que l'utilisateur est redirigé vers / contrôleur / résultat . .
-
/ contrôleur / résultat récupère le résultat de tempdata et les rend les rendez à l'utilisateur.
Le problème avec cette approche est que si l'utilisateur frappe F5 lors de la visualisation des résultats dans / Controller / Résultat La page ne peut plus être rendue comme templdata a été expiré et l'objet de résultat n'est plus disponible. Ce comportement n'est pas souhaité par les utilisateurs. Une solution possible serait au lieu de rediriger après le poste, rendant simplement la vue Résultats. Maintenant, si l'utilisateur frappe F5, il reçoit un dialogue de navigateur qui demande s'il veut republier le formulaire. Cela n'était également pas souhaité.
Une solution possible que j'ai pensé était de sérialiser l'objet de résultat et de le transmettre à l'URL avant de rediriger mais afaik il y a quelques limitations dans la durée d'une demande d'obtention et si l'objet devient assez grand que je pourrais frapper Cette limitation (surtout si la base64 codée).
Une autre possibilité serait d'utiliser l'objet de session au lieu de tempdata pour persister les résultats. Mais avant de mettre en œuvre cette solution, je voudrais savoir s'il y a une meilleure façon de le faire.
Mise à jour:
Enquêter plus avant la question que j'ai découvert que si je re mettre l'objet de résultat dans templdata à l'intérieur du / contrôleur / résultat action Ça fonctionne réellement: xxx mais cela se sent gentil de sale. Pourrait-il y avoir des effets secondaires avec cette approche (telle que la commutation aux fournisseurs de session hors traitement, comme j'utilise actuellement INPROCC)?
5 Réponses :
Tempdata est généralement considéré comme utile pour passer des messages de retour à l'utilisateur qui ne permet pas de stocker des entités de travail (un usage de l'utilisateur ne vous écrasera pas le contenu de TempData).
Je ne connais pas l'endroit plus approprié que la session pour stocker ce type d'information. Je pense que l'idée générale est de garder la session aussi petite que possible. Personnellement, j'écris habituellement des wrappers pour ajouter et supprimer des objets spécifiques à la session. Les nettoyer manuellement lorsque cela est possible.
Vous pouvez également stocker dans une base de données dans laquelle vous purgeez des articles rassis sur une base régulière.
Stockez-le dans la session avec une clé unique et transmettez la clé dans le cadre de l'URL. Ensuite, tant que la session est en vie, elles peuvent utiliser le bouton arrière / avancement du contenu de leur cœur et que l'URL réagit correctement. Alternativement, vous pouvez utiliser le cache ASP, mais je réserve normalement cela pour des objets partagés entre les utilisateurs. Bien sûr, si vous utilisiez les paramètres dans le calcul comme clé et que vous avez trouvé le résultat dans le cache, vous pouvez simplement la réutiliser.
Merci, c'est une bonne suggestion. J'essaierais de le mettre en œuvre avec une clé unique transmise dans l'URL.
Je pense que rediriger après que la poste ait beaucoup plus de sens lorsque l'URL résultante est significative. Dans votre cas, cela signifierait que toutes les données requises pour le calcul sont dans l'URL de / contrôleur / résultat.
/ contrôleur / calculer ne ferait pas le calcul mais / contrôleur / résultat.
Si vous pouvez le faire, les pensées devraient être assez faciles: vous haussez les valeurs requises pour le calcul et utilisez-la comme clé du cache. Si l'utilisateur rafraîchit, il ne frappe que le cache.
Si vous ne pouvez pas avoir une URL significative, vous pouvez poster sur / contrôleur / index. Si l'utilisateur frappe le calcul F5 recommencerait, mais une cache avec le hachage comme clé aiderait à nouveau.
Je dois valider l'entrée avant de calculer et s'il y a une erreur indique le même formulaire avec des valeurs pré-remplies et des champs d'erreur marqués en rouge. Si le calcul a été effectué dans l'action de résultat, comment géreriez-vous des erreurs de modélisation? Devrais-je rediriger vers l'action de l'index et remettre à nouveau toutes les valeurs d'entrée et les erreurs de validation à la tempdata afin de pouvoir afficher correctement le formulaire?
Son plus difficile d'avoir une validation en résultat. Je me redirierais avec des valeurs validées. Le moyen le plus simple est de poster pour indexer et valider des erreurs de données / affichage.
Je pourrais adopter une idée similaire à beaucoup de banques sur leurs bancs de banque en ligne en utilisant des clés ponctuelles pour vérifier tous les messages. Vous pouvez l'intégrer à une aide HTML pour les formulaires et dans votre couche de service (par exemple) pour vérification.
Disons que vous ne voulez que poster une instance d'un formulaire une fois. Ajouter un GUID au formulaire. Si le formulaire ne post pas en arrière et que les données sont engagées, vous souhaitez invalider le GUID et rediriger vers l'action d'obtention. Si vous indiquez que le formulaire n'était pas valide, lorsque la page vous écrit, vous avez besoin d'une nouvelle adresse (valide), dans le formulaire en attente de la prochaine tentative postale.
Les GUID sont générés selon les besoins et ajoutés à une table dans votre DB. Comme ils sont invalidés (par des messages, qu'ils soient réussis ou non), ils sont signalés dans la table. Vous voudrez peut-être couper la table à 100 rangées. Ou 1000, en fonction de la taille de votre application et du nombre de formulaires rendus mais non encore affichés que vous pouvez avoir à la fois.
Je n'ai pas vraiment bien réglé ce design mais je pense que cela pourrait fonctionner. Ce n'est pas aussi malodorant que la tempdata et vous pouvez toujours adhérer au modèle PRG.
N'oubliez pas, avec PRG que vous ne souhaitez pas envoyer les nouvelles données à l'action d'obtention d'une variable TEMP de quelque sorte. Vous souhaitez la questionner dans le magasin de données, où il est maintenant attaché à.
Actuellement, l'application n'a pas de dataStore. Il effectue tout le travail en mémoire (uniquement des calculs et aucune persistance). C'est pourquoi j'ai envisagé d'utiliser des tempdata ou une session en tant que DataStore temporaire.
Comme Michael a déclaré, Tempdata a un seul but -> Stockez un objet pour un voyage et un seul voyage. Si je comprends bien, Tempdata utilise essentiellement le même objet de session que vous pourriez utiliser, mais il supprimera automatiquement l'objet de la session lors du prochain voyage.
Stick avec session IMHO plutôt que de repousser à Tempdata.
Quand vous dites "Rediriger" appelez-vous RedirectToaction?