Pregunta

Me estoy moviendo de ASP clásico a ASP.NET y he encontrado lo que muchos de ustedes ya conocen como "viewstate". Podría estar saltando el arma con mi suposición, pero se ve muy engorroso. He desarrollado muchos formularios ASP en el pasado y nunca tuve problemas para mantener el estado. ¿Hay alguna otra manera O voy a tener que aprender esto de Viewstate en ASP.NET? Estoy usando Visual Studio 2008, VB.NET como el código detrás del lenguaje y Framework v3.5 con SQL Server 2005.

¿Fue útil?

Solución

No tienes que hacerlo. Echa un vistazo a MVC framework . Elimina ViewState y funciona como ASP antiguo (al menos desde este punto de vista).

Otros consejos

Esta serie de publicaciones debe leerse para entender ViewState

Lo deshabilito y hago la mayor parte de mi trabajo en Page_Init en lugar de Load (los valores todavía se mantienen debido a ControlState). Esta configuración me ha funcionado bien.

ViewState es opcional, pero útil. Qué es ViewState, son todos los cambios que ocurren en un control en el LADO DEL SERVIDOR. Entonces, si está asignando texto a una etiqueta, y desea que el texto persista sin la necesidad de reasignarlo en cada devolución de datos, entonces querrá mantenerlo. Otro ejemplo en el que siempre dejo ViewState es cualquier archivo de datos.

Dicho esto, hay ocasiones en que es útil desactivar ViewState por el mismo motivo. Por ejemplo, el único lugar donde siempre desactivo ViewState es una etiqueta de MENSAJE. De esa manera, cuando tengo que imprimir un mensaje para el usuario (uno que solo debería aparecer una vez y luego desaparecer) simplemente agrego el texto a la etiqueta y luego me olvido. Durante el próximo PostBack, la etiqueta volverá automáticamente al texto que se encuentra en la declaración ASPX para ese control (en este caso, una cadena vacía).

Ahora, tenga en cuenta que esto no tiene nada que ver con la colección de formularios, que son los valores publicados en IIS durante el PostBack. La colección de formularios envía los valores que el usuario ingresa en los elementos del formulario (cuadros de texto, casillas de verificación, listas desplegables, etc.). Estos .NET se llenarán en el lugar apropiado, y esto ocurre DESPUÉS Se ha procesado ViewState.

De esta manera, si envía un cuadro de texto con la frase " hola allí " para el cliente, el usuario lo cambia a " See ya " y luego envía el formulario, lo que tendrá el cuadro de texto para cuando se active el evento Page_Load es un cuadro de texto con "Nos vemos" en el atributo TEXTO.

En ASP clásico siempre usamos un campo OCULTO para hacer el trabajo. Viewstate es solo una forma de hacerlo automáticamente. Confía en mí, la curva de aprendizaje no es tan alta como podrías pensar.

Algunos controles están profundamente paralizados cuando desactivas ViewState, así que prepárate para resolver estos problemas. Es más fácil ser perezoso y dejarlo encendido, pero si no se selecciona, ViewState puede representar fácilmente el 30% del tamaño de su HTML.

Por ejemplo, supongamos que tiene un DropDown y lo enlaza a una lista de Frutas. Lo enlaza en el bloque if (! IsPostBack) {} en la carga de la página. Si desactiva ViewState, perderá los elementos al hacer clic en un botón. Deben estar vinculados cada carga de página. También perderá su índice seleccionado, por lo que necesitaría sacarlo de las variables Request.Form [].

Viewstate es parte del paquete cuando trabaja con ASP.NET. Para una página / sitio web básico no debería tener que 'saber' cómo usar Viewstate. Simplemente se usa cuando pones controles en las páginas.

Es bastante difícil evitar Viewstate con ASP.NET porque incluso si lo desactiva a nivel de proyecto, algunos controles individuales aún usan Viewstate para conservar su información.

Si no desea tratar con Viewstate, considere usar el framework ASP.NET MVC. Es probable que se sienta más cómodo con el marco MVC que proviene de ASP clásico.

ViewState es completamente opcional en casi todos los casos, si no todos. ASP.NET vuelve a llenar los campos automáticamente incluso si ViewStateEnabled = false. He estado usando ASP.NET durante 5 o 6 años y nunca he tenido que depender de ViewState. Incluso lo deshabilito cuando puedo.

ViewState funciona automáticamente en su mayor parte. Así es como ASP.NET realiza un seguimiento del estado actual de todos sus controles.

También puede usar viewstate manualmente, si desea almacenar algunos datos adicionales. Eso es tan simple como:

Viewstate["Key"] = value;

La única advertencia es que cualquier objeto que almacene en viewstate debe ser serializable.

Definitivamente puedo recomendar evitar ViewState en DataGrids y DropDownLists porque recientemente empecé a hacerlo yo mismo. No hice esto por diversión, tuve que arreglar una página que había crecido tanto que estaba causando otros problemas. Pero esto resultó ser fácil, y los resultados fueron tan dramáticos que estoy muy satisfecho. Por supuesto, para una aplicación pequeña y simple o para pequeñas cantidades de datos, esto no será necesario, pero por otro lado es bueno ser consistente (siempre pase de lo conocido a lo conocido para que pueda mejorar continuamente su proceso ...), y por qué llevar equipaje extra, ¿alguna vez?

Esto requerirá una pequeña intervención manual de su parte. Por ejemplo, si desactiva viewstate para las listas desplegables, tendrá que volver a vincularlas en cada devolución y, a continuación, restaurar el SelectedValue del objeto Request. Tendrá que leer sobre esto, pero Google tiene mucha información fácilmente disponible.

Viewstate se mantiene automáticamente para los controles asp.net "enraizados" a la pagina Hay poco que hacer, los valores y otra información se pasa en una entrada oculta codificada B64. Puede verlo si lo desea, pero no importa, todo se maneja automáticamente para usted.

Si está escribiendo un código para su propio consumo, simplemente puede desactivarlo y no preocuparse.

Presumiblemente, va a mantener el código de formularios web escrito por otras personas, por lo que debe saber cuáles son las opciones de configuración y los puntos débiles. Pocos en los que puedo pensar

  • cómo deshabilitarlo en el sitio, la página y el nivel de control
  • por qué MachineKey es relevante en granjas web
  • por qué su registro de eventos está lleno de errores de autenticación de ViewState
  • qué es ViewStateUserKey

En términos de la curva de aprendizaje real, esta es probablemente una lectura exhaustiva de un par de artículos de MSDN.

ViewState es un mal necesario inherente a la metáfora de formularios web. Personalmente, encuentro que esta metodología es obsoleta, abultada y, en general, no es compatible con la web. Mejor revisa el marco MVC como se sugirió anteriormente.

Le sugiero que evite la tentación de usar ViewState como " caché " para pasar datos de un lado a otro (he visto sitios web haciendo esto debido a la configuración en clúster y sin estado de sesión respaldado por SQL). Los datos se serializan y se agregan a la página y deben hacer viajes de ida y vuelta a cada solicitud, lo que aumenta el tamaño total de la página y hace que su sitio se cargue más lentamente.

'<%@ 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>
'
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top