Question

Je passe d'ASP classique à ASP.NET et j'ai déjà rencontré ce que beaucoup d'entre vous connaissent déjà sous le nom de "viewstate". Mon hypothèse est peut-être différente, mais cela semble extrêmement lourd. J'ai développé de nombreux formulaires ASP par le passé et je n’ai jamais eu de problèmes de maintien de l’état. Existe-t-il un autre moyen OU vais-je devoir apprendre cette chose Viewstate dans ASP.NET? J'utilise Visual Studio 2008, VB.NET comme code de langage et Framework v3.5 avec SQL Server 2005.

Était-ce utile?

La solution

Vous n'êtes pas obligé. Consultez le framework MVC . Il élimine ViewState et fonctionne comme un ancien ASP (du moins de ce point de vue).

Autres conseils

Cette série de posts est à lire absolument pour comprendre ViewState

Je le désactive et effectue l'essentiel de mon travail dans Page_Init au lieu de Load (les valeurs sont toujours conservées à cause de ControlState). Cette configuration a bien fonctionné pour moi.

ViewState est facultatif, mais utile. ViewState correspond à tous les changements qui se produisent sur un contrôle du côté serveur. Ainsi, si vous attribuez du texte à une étiquette et que vous souhaitez que ce texte soit conservé sans qu'il soit nécessaire de le réaffecter à chaque publication, vous souhaiterez le conserver. Un autre exemple où je laisse toujours ViewState est tout ce qui est databound.

Cela dit, il est parfois utile de désactiver ViewState pour la même raison. Par exemple, le seul endroit où toujours éteint ViewState est une étiquette MESSAGE. Ainsi, lorsque je dois imprimer un message à l'utilisateur (un message qui ne doit apparaître qu'une fois, puis disparaître), j'ajoute simplement le texte à l'étiquette, puis je l'oublie. Lors du prochain PostBack, l’étiquette reviendra automatiquement au texte trouvé dans la déclaration ASPX de ce contrôle (dans ce cas une chaîne vide).

Notez que cela n’a rien à voir avec la collection de formulaires, qui sont les valeurs publiées dans IIS lors de la publication. La collection de formulaires envoie les valeurs que l'utilisateur entre dans les éléments de formulaire (zones de texte, cases à cocher, listes de dépôt, etc.). Ces fichiers .NET seront placés à l'emplacement approprié - et cela se produit APRÈS ViewState a été traité.

Ainsi, si vous envoyez une zone de texte avec la phrase "hi there" pour le client, l’utilisateur le remplace par "Je vois". et soumet ensuite le formulaire, ce que la zone de texte aura au moment où l'événement Page_Load est déclenchée est une zone de texte avec le message "See ya". dans l'attribut TEXT.

En ASP classique, nous avons toujours utilisé un champ HIDDEN pour effectuer le travail. Viewstate n'est qu'un moyen de le faire automatiquement. Croyez-moi, la courbe d'apprentissage n'est pas aussi élevée que vous ne le pensez.

Certaines commandes sont profondément endommagées lorsque vous désactivez ViewState. Soyez donc prêt à résoudre ces problèmes. Il est plus facile de rester paresseux et de le laisser allumé, mais si rien n'est fait, ViewState peut facilement représenter 30% de la taille de votre code HTML.

Par exemple, supposons que vous avez un DropDown et que vous le liez à une liste de Fruits. Vous le liez dans le bloc if (! IsPostBack) {} lors du chargement de la page. Si vous désactivez ViewState, vous perdez les éléments lorsque vous cliquez sur un bouton. Ils doivent être liés à chaque chargement de page. Vous perdrez également votre index sélectionné. Vous devez donc le retirer des variables Request.Form [].

Viewstate fait partie du package lorsque vous utilisez ASP.NET. Pour une page / site Web de base, vous ne devriez pas avoir à "savoir" comment utiliser Viewstate. Il est simplement utilisé lorsque vous mettez des contrôles sur des pages.

Il est assez difficile d'éviter Viewstate avec ASP.NET car même si vous le désactivez au niveau du projet, certains contrôles utilisent toujours Viewstate pour conserver leurs informations.

Si vous ne souhaitez pas utiliser Viewstate, envisagez d’utiliser le framework ASP.NET MVC. Vous serez probablement plus à l'aise avec le framework MVC provenant de Classic ASP.

ViewState est complètement facultatif dans presque tous les cas, voire tous. ASP.NET renseigne automatiquement les champs même si ViewStateEnabled = false. J'utilise ASP.NET depuis 5 ou 6 ans et je n'ai jamais eu à dépendre de ViewState. Je le désactive même quand je peux.

ViewState fonctionne automatiquement pour la plupart. C’est la façon dont ASP.NET garde trace de l’état actuel de tous ses contrôles.

Vous pouvez également utiliser manuellement viewstate si vous souhaitez stocker des données supplémentaires. C’est aussi simple que:

Viewstate["Key"] = value;

La seule réserve à cela est que tout objet que vous stockez dans Viewstate doit être sérialisable.

Je peux sans aucun doute vous recommander d'éviter ViewState dans DataGrids et DropDownLists car je viens tout juste de commencer à le faire moi-même. Je ne le faisais pas pour le plaisir, je devais corriger une page qui était devenue tellement grande qu'elle posait problème. Mais cela s’est avéré facile et les résultats ont été si dramatiques que je suis très heureux. Bien sûr, pour une petite application simple ou pour de petites quantités de données, cela ne sera pas nécessaire, mais d'un autre côté, il est bon d'être cohérent (passez toujours de connu à connu pour pouvoir améliorer continuellement votre processus ...), et pourquoi transporter des bagages supplémentaires, jamais?

Cela nécessitera une petite intervention manuelle de votre part. Par exemple, si vous désactivez viewstate pour les listes déroulantes, vous devez les réassocier à chaque publication, puis restaurer la SelectedValue à partir de l'objet Request. Vous aurez besoin de lire à ce sujet, mais Google a beaucoup d'informations facilement disponibles.

Viewstate est automatiquement conservé pour les contrôles asp.net " rooted " à la page. Vous avez peu de choses à faire, les valeurs et certaines autres informations sont transmises dans une entrée cachée codée en B64. Vous pouvez l'examiner si vous le souhaitez, mais cela n'a pas d'importance, tout est géré automatiquement pour vous.

Si vous écrivez du code pour votre propre consommation, vous pouvez simplement le désactiver et ne pas vous inquiéter.

Vraisemblablement, vous allez conserver le code Web Forms écrit par d’autres personnes. Vous devez donc connaître les options de configuration et les difficultés rencontrées. Je pense à quelques-uns des

  • comment le désactiver au niveau du site, de la page et du contrôle
  • Pourquoi MachineKey est-il pertinent dans les batteries de serveurs Web
  • pourquoi votre journal des événements est rempli d'erreurs ViewStateAuthentication
  • qu'est-ce que ViewStateUserKey

En termes de courbe d’apprentissage réelle, il s’agit probablement d’une lecture approfondie de deux articles MSDN.

ViewState est un mal nécessaire inhérent à la métaphore des formulaires Web. Personnellement, je trouve cette méthodologie obsolète, gonflée et généralement pas adaptée au Web. Mieux vaut consulter le framework MVC comme suggéré ci-dessus.

Je vous suggère d'éviter la tentation d'utiliser ViewState en tant que "cache". pour transmettre des données dans les deux sens (j'ai vu des sites Web le faire en raison de la configuration en cluster et de l'absence d'état de session reposant sur SQL). Les données sont sérialisées et ajoutées à la page. Elles doivent effectuer des allers-retours à chaque requête, en ajoutant à la taille totale de la page et en ralentissant le chargement de votre site.

'<%@ Control Language="C#" AutoEventWireup="true" CodeFile="HomePage.ascx.cs" Inherits="HomePage" %>
<script runat="server">
  void testHF_ValueChanged(object sender, EventArgs e)
    {
       this.HFvalue.Text = this.testHF.Value ;

    }
</script>
<asp:Label ID="UserNamelbl" runat="server" Text="User Name : " Visible="false"></asp:Label>
<asp:TextBox ID="UserNametxt" runat="server" Visible="false" ></asp:TextBox>
 <asp:Label ID="HFvalue" Text="......" runat="server"></asp:Label>
 <asp:HiddenField ID="testHF"
OnValueChanged="testHF_ValueChanged"
value="" 
runat="server" ></asp:HiddenField>
<input type="submit" name="SubmitButton" value="Submit" onclick="CL()" />

<script type="text/javascript">
    function CL() 
    {
        this.testHF.Value = this.UserNametxt.Text;  
    }
</script>
'
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top