asp.net c # MVC: Comment vivre sans ViewState?
Je cherche juste à convertir des WebForms en MVC:
Dans .net MVC, quels concepts font de ViewState quelque chose de non requis?
Si un formulaire est posté sur lui-même, etc. (c'est-à-dire un postback)? comment la page/l'utilisateur contrôle-t-elle son état?
Quelles astuces les gens font-ils pour maintenir une sorte d'état et ne pas recourir à l'état de session?
Sûrement, un environnement complètement apatride ne peut pas exister?
Mais bien sûr, c'est possible. En fait, le Web est sans état. Toute pensée contraire est en fait l'aberration.
Les contrôles Web ont disparu dans MVC. Aucun événement ne se déclenche côté serveur. Ceci est remplacé par deux mécanismes différents - URL et données de formulaire POSTing. Une utilisation appropriée de ceux-ci remplacera votre besoin de ViewState.
Dans une application Web ASP.NET conventionnelle, vous placeriez un LinkButton sur votre page Web qui exécuterait la fonction X. ASP.NET collerait un grand nombre de fichiers ViewState, javascript et autres dans la page Web de sorte que, lorsque l'utilisateur clique sur le bouton et "publie" sur le site Web (en soumettant un formulaire dont personne ne sait l'existence), ASP.NET reconstruit ce qui s'est passé et détermine qu'un gestionnaire d'événements de bouton particulier doit être exécuté.
Dans MVC, vous créez votre lien pour accéder à un itinéraire particulier. L'itinéraire décrit ce que l'utilisateur souhaite faire -/Utilisateurs/Délinquant/Index (afficher une liste de tous les utilisateurs délinquants). Le système de routage dans MVC détermine quel contrôleur traitera cette route et quelle méthode sur ce contrôleur exécutera. Toute information supplémentaire peut être transmise à la méthode du contrôleur par des valeurs de chaîne de requête URL (? Page = 5 pour la 5ème page des délinquants).
En plus des URL, vous pouvez utiliser des formulaires HTML pour POST sauvegarder des informations plus complexes (telles que la valeur d'un formulaire) ou des éléments qui ne rentrent pas dans une chaîne de requête, comme un fichier .
Donc, vous "maintenez" l'état via des chaînes de requête et formez POST. Vous constaterez qu'en fait, il n'y a pas beaucoup d'état à maintenir à la fin. En fait, avoir à maintenir beaucoup d'état est une bonne indication que votre conception manque ou que vous essayez de faire quelque chose qui ne correspond pas à un modèle de site Web.
Quelques questions connexes:
Dans la plupart des langages Web traditionnels, le concept d'un environnement avec état est en fait assez rare. ASP.NET Webforms est une exception à la règle et il crée cette exception en réinventant un grand nombre de normes. L'objectif de Webforms est essentiellement d'abstraire le concept de HTML et de développement Web en général afin que la frontière entre l'application de bureau et l'application Web se brouille du point de vue du développement. Ce que cela signifie généralement, c'est que la solution qu'ASP.NET Webforms fournit, bien qu'efficace, est une implémentation polyvalente qui se traduit par une sortie très verbeuse qui fonctionne assez bien pour satisfaire la plupart. Inversement, le principal avantage d'ASP.NET MVC est qu'il redonne le contrôle de la sortie HTML au développeur et lui permet de créer des applications Web RESTful fortement architecturées qui sont mieux définies et plus propres dans leur implémentation et présentation - en dépit de sacrifier un certain niveau de commodité.
On peut soutenir que l'un des plus gros inconvénients du modèle Webforms est le ViewState car il encombre la sortie, augmente considérablement la taille de la page dans certains scénarios et équivaut souvent à utiliser un marteau-piqueur pour suspendre une image. Plutôt que d'essayer d'utiliser ViewState dans votre application MVC (ou tout ce qui lui ressemble), vous devriez commencer à utiliser des modèles qui contrôlent explicitement les champs dans vos formulaires et optimisent vos opérations d'entrée et de sortie avec uniquement les données les plus pertinentes. En plus des modifications du balisage, vous apprendrez également à créer des solutions mieux conçues qui peuvent être exposées au sein de votre application et en externe.
La comparaison numéro un que j'aime faire est simplement: Webforms crée des pages Web, mais MVC crée des applications Web. Si votre travail quotidien consiste principalement à créer des éléments d'un site Web ou à ajouter de petites fonctionnalités, vous constaterez souvent que les formulaires Web sont beaucoup plus faciles et prennent moins de temps; d'autre part, si vous souhaitez créer une application complète testable, évolutive et flexible, MVC est votre appel.
viewstate est juste un grand champ de formulaire caché.
Écrivez vos propres champs de formulaire cachés et chiffrez-les si nécessaire.
Heureusement, il n'y a plus de moyen simple de transférer des tas de données dans la page, vous devez donc être judicieux sur ce que vous voulez enregistrer.
Si un formulaire est posté sur lui-même, etc. (c'est-à-dire un postback)? comment la page/l'utilisateur contrôle-t-elle son état? Quelles astuces les gens font-ils pour maintenir une sorte d'état et ne pas recourir à l'état de session?
Le ViewData publié (ou l'objet fortement typé lié à la page) peut être poussé à nouveau vers la vue. Voir "Intégration de la validation et de la logique des règles métier aux classes de modèle" dans cette page. Il montre comment vous pouvez publier un formulaire, validez-le et renvoyez les champs au formulaire en cas d'erreur.
Dans .net MVC, quels concepts font de ViewState quelque chose de non requis?
Toutes les réponses indiquant qu'ASP.NET MVC n'utilise pas d'état sont à peu près correctes. Mais ASP.NET MVC utilise en fait un certain état, bien qu'il ne fonctionne pas du tout comme ViewState.
Habituellement, lorsque quelqu'un POSTE des données sur votre application, vous souhaiterez valider les données et afficher une erreur si les données ne sont pas valides. Cependant, si vous retournez immédiatement la page contenant le message d'erreur, lorsque l'utilisateur frappe F5 pour recharger la page, les données seront à nouveau soumises. Ce n'est généralement pas ce que vous voulez. Ainsi, lorsque vous réalisez que les données POSTées ne sont pas valides, vous voulez dire aux utilisateurs d'obtenir la page (ou peut-être une autre page) et afficher un message d'erreur. Pour ce faire, vous retournez un code d'état HTTP Redirect. Cependant, une fois que la demande GET de l'utilisateur est entrée, comment savez-vous quel message d'erreur afficher? Vous devrez en quelque sorte vous en souvenir depuis le moment où vous (le serveur) manipulez le POST jusqu'à ce que vous manipuliez le GET.
Pour ce faire, vous utilisez une fonctionnalité ASP.NET MVC appelée TempData. Il s'agit en fait d'un simple wrapper autour de Session qui garantit que tout ce que vous insérez dans le dictionnaire TempData y restera jusqu'à la prochaine demande et non plus.
MVC a quelques avantages par rapport aux WebForms mais il a aussi quelques inconvénients ainsi que j'ai couvert les détails dans cette réponse . Je pense que la question fondamentale que vous devez vous poser est de savoir si ViewState est un problème pour vous maintenant - et est-ce un problème tel que vous devez réécrire votre application? Sinon, alors apprendre MVC est un objectif louable (c'est vraiment assez cool) mais pas pour lequel je risquerais des affaires.
Cela étant dit, ViewState peut en fait être désactivé dans un nombre étonnamment élevé de cas. Il est utilisé principalement pour conserver la valeur des contrôles via un post-back. Ainsi, par exemple, si vous avez une zone de texte dont vous devez vérifier la valeur côté serveur ainsi qu'un tas d'autres champs, ViewState vous permettra de gérer le post-back, de détecter l'erreur (et d'afficher une étiquette), puis renvoyer l'utilisateur au formulaire avec toutes ses entrées intactes. Cependant, si un formulaire est seulement à remplir et à publier et que vous serez ensuite redirigé vers une autre page, vous pouvez le désactiver en toute sécurité.
Enfin, vous demandez ce que les gens font pour éviter l'état de session. Y a-t-il une raison d'éviter l'état de session? Vous ne voulez sûrement pas beaucoup d'informations là-bas, mais l'éviter complètement n'est vraiment pas nécessaire et, en fait, vous coûtera l'un des outils les plus puissants de votre arsenal.
Considérez le fait que le mouvement REST dans la programmation Web est basé sur l'idée que l'état est mauvais pour un programme. Le Wikipedia a une description décente avec des références: http://en.wikipedia.org/wiki/Representational_State_Transfer
Venant d'ASP.NET tranditional et du modèle d'événement riche qu'il fournit, MVC peut être assez choquant. Cela nécessite de gérer des choses qui vous étaient auparavant invisibles, mais je pense que la valeur en termes de testabilité (les pages REST peuvent être déclenchées facilement sans créer un état de vue complexe et, par définition, le serveur ne tient pas l'état afin que je puisse tester une page/fonctionnalité de manière isolée) compense la courbe d'apprentissage.
Pour une discussion de MVC dans ASP.NET et REST: http://blog.wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture/
L'état est le modèle qui se trouve dans la base de données. Vous pouvez soigneusement mettre en cache la base de données pour réduire les temps de chargement des pages.
L'état d'affichage généré automatiquement n'existe pas dans MVC, mais vous pouvez écrire le vôtre simplement en utilisant des champs masqués,
Dans MVC, vous ne verrez pas beaucoup de caractères chiffrés en haut de la page dont vous n'avez pas besoin de la plupart d'entre eux.
Vous pouvez imiter l'état d'affichage avec projet MVC3Futures . Il sauvera tout le modèle en vue.
Tout ce que vous avez à faire est de sérialiser le modèle et de le crypter en vue.
@Html.Serialize("Transfer", Model, SerializationMode.EncryptedAndSigned)
Et dans le contrôleur, ajoutez un attribut désérialisé.
public ActionResult Transfer(string id,[Deserialize(SerializationMode.EncryptedAndSigned)]Transfer transfer)
En fait, c'est le cas. Vous devez oublier la façon dont la persistance a été constituée avec le viewstate.
Vous devez également convertir dans votre esprit la publication sur une page pour "appeler un contrôleur". De cette façon, les choses seront plus faciles à comprendre par la suite. Au lieu d'appeler une page, vous appelez un contrôleur qui renvoie une vue. Donc, soit vous construisez votre "page" entière encore et encore à chaque appel, soit vous décidez de ne traiter que ce qui est vraiment impacté par l'action. Si le bouton change une div, pourquoi recharger la page entière. Il vous suffit d'appeler votre contrôleur et de renvoyer quelles devraient être les nouvelles données de votre div.
par exemple, imaginons un scénario maître/détail:
<h2>Groups</h2>
<div id="GroupList">
</div>
<div id="GroupDetail" title="Detail Group">
</div>
La liste de groupe est chargée une fois dans le div et il y a un appel ajax possible à un contrôleur pour chaque élément de la liste de groupe:
<%= Ajax.ActionLink("Edit", "DetailLocalisationGroup",
new { id = group.Id },
new AjaxOptions() {
UpdateTargetId = "DetailLocalisationGroup",
OnSuccess = "InitialisationDetailGroup" })%>
qui appelle cette action DetailLocalisationGroup qui consiste à alimenter le div GroupDetail en html.
[AcceptVerbs("POST")]
public ActionResult DetailLocalisationGroup(int id)
{
LocalisationGroup group = servicelocalisation.GetLocalisationGroup(id);
return View("DetailGroup", group);
}
Il y a maintenant un formulaire dans la div, et lorsque vous appuyez sur le bouton d'envoi de ce formulaire, nous envoyons simplement les informations dont nous avons vraiment besoin à un contrôleur qui enregistrerait ensuite les données dans la base de données.
Pendant tous ces événements, la GroupList était remplie de choses qui étaient affichées sur l'écran du client, mais aucune interaction n'était nécessaire là-bas, alors pourquoi s'embêter avec un état de vue pour ces derniers ...
Après avoir lu tous ces messages, il semble que MVC n'est pas bon pour les applications de type LOB, où vous aurez beaucoup de contrôles et d'opérations CRUD et que vous souhaitiez maintenir l'état des contrôles. Il existe de nombreuses raisons pour lesquelles vous souhaitez que l'utilisateur reste dans la même vue et maintienne son état une fois les opérations de soumission terminées. Par exemple, pour afficher des erreurs, des messages de validation côté serveur, des messages de réussite ou pour effectuer toute autre action. rediriger l'utilisateur vers une autre vue pour afficher ces messages n'est pas pratique.
Vous pouvez stocker n'importe quel objet dans l'état de session.
HttpContext.Session["userType"] = CurrentUser.GetUserType();