from - asp.net c#MVC: ¿Cómo vivo sin ViewState?
web forms c# ejemplos (13)
¿Si un formulario se publica en sí mismo, etc. (es decir, una devolución)? ¿Cómo mantiene la página / usercontrol su estado? ¿Qué trucos están haciendo las personas para mantener algún tipo de estado y no recurrir al estado de sesión?
El ViewData publicado (o el objeto fuertemente tipado vinculado a la página) se puede empujar nuevamente a la vista. Consulte "Integración de lógica de validación y reglas de negocios con clases modelo" en esta página. Muestra cómo puede publicar un formulario, validarlo y devolver los campos al formulario si se produce un error.
En .net MVC, ¿qué conceptos hacen que ViewState sea algo que no es necesario?
Solo estoy buscando convertir WebForms a MVC:
En .net MVC, ¿qué conceptos hacen que ViewState sea algo que no es necesario?
¿Si un formulario se publica de nuevo en sí mismo, etc. (es decir, una devolución)? ¿Cómo mantiene la página / usercontrol su estado?
¿Qué trucos están haciendo las personas para mantener algún tipo de estado y no recurrir al estado de sesión?
Seguramente, ¿no puede existir un entorno completamente sin estado?
Algunas preguntas relacionadas:
En la mayoría de los lenguajes web tradicionales, el concepto de un entorno con estado es realmente poco común. Los formularios web de ASP.NET son una excepción a la regla y crean esa excepción reinventando muchos estándares. El objetivo de Webforms es esencialmente abstraer el concepto de HTML y el desarrollo web en general, de modo que la línea entre la aplicación de escritorio y la aplicación web se difumine desde el punto de vista del desarrollo. Lo que generalmente significa esto es que la solución que proporcionan los formularios web de ASP.NET, aunque es efectiva, es una implementación de todos los comercios que da como resultado una salida muy detallada que funciona lo suficientemente bien como para satisfacer a la mayoría. Por el contrario, la ventaja principal de ASP.NET MVC es que le devuelve el control de salida HTML al desarrollador y les permite crear aplicaciones web RESTful con una arquitectura RESTful , mejor definidas y más limpias en su implementación y presentación, a pesar de sacrificar cierto nivel de conveniencia.
Podría decirse que uno de los mayores inconvenientes del modelo Webforms es el ViewState porque desordena la salida, aumenta el tamaño de la página dramáticamente en ciertos escenarios, y es a menudo el equivalente a usar un martillo neumático para colgar una imagen. En lugar de intentar utilizar ViewState en su aplicación MVC (o cualquier cosa que se le parezca), debe comenzar a usar patrones que controlan explícitamente los campos de sus formularios y optimizan sus operaciones de entrada y salida con solo los datos más relevantes. Además de los cambios en el marcado, también aprenderá a crear soluciones mejor diseñadas que pueden ser expuestas dentro de su aplicación y externamente.
La comparación número uno que me gusta hacer es simplemente: Webforms construye páginas web, pero MVC construye aplicaciones web. Si su trabajo diario consiste principalmente en crear partes de un sitio web, o agregar pequeñas porciones de funcionalidad, a menudo encontrará que los formularios web son mucho más fáciles y requieren menos tiempo; Por otro lado, si desea crear una aplicación completa que sea comprobable, escalable y flexible, MVC es su vocación.
Considere el hecho de que el movimiento REST en la programación web se basa en la idea de que el estado es malo para un programa. La Wikipedia tiene una descripción decente con referencias: http://en.wikipedia.org/wiki/Representational_State_Transfer
Al provenir de tranditional ASP.NET y del rico modelo de eventos que proporciona, MVC puede ser bastante discordante. Requiere administrar algunas cosas que antes eran invisibles para usted, pero creo que el valor en términos de capacidad de prueba (las páginas REST se pueden activar fácilmente sin crear un estado de visualización complejo y, por definición, el servidor no tiene un estado así que puedo probar página / característica en aislamiento) compensa la curva de aprendizaje.
Para una discusión sobre MVC en ASP.NET y REST: http://blog.wekeroad.com/2007/12/06/aspnet-mvc-using-restful-architecture/
Después de leer todas estas publicaciones, parece que MVC no es bueno para el tipo de aplicaciones LOB, donde tendrá muchos controles y operaciones CRUD y desea mantener el estado de los controles. Hay muchas razones por las que desea que el usuario permanezca en la misma vista y mantenga el estado después de que se realicen las operaciones de envío. Por ejemplo, para mostrar errores, mensajes de validación del lado del servidor, mensajes de éxito o para realizar cualquier otra acción. redirigir al usuario a otra vista para mostrar estos mensajes no es práctico.
El estado de vista generado automáticamente no existe en MVC, pero puede escribir su propio simplemente usando campos ocultos,
En MVC no verás muchos caracteres cifrados en la parte superior de la página que no necesitas la mayoría de ellos.
El estado es el modelo que se encuentra en la base de datos. Puede guardar cuidadosamente la base de datos para reducir los tiempos de carga de la página.
En realidad lo hace. Tienes que olvidar la forma en que se hizo la persistencia con el estado visual.
También tiene que convertir en su mente la devolución de datos en una página para "llamar a un controlador". De esta manera las cosas serán más fáciles de entender después. En lugar de llamar a una página, estás llamando a un controlador que devuelve una vista. Entonces, o bien estás construyendo tu "página" completa una y otra vez en cada llamada, o decides tratar solo con lo que realmente está afectado por la acción. Si el botón está cambiando un div, ¿por qué volver a cargar toda la página. Simplemente haga que llame a su controlador y devuelva lo que deberían ser los nuevos datos en su div.
por ejemplo, imaginemos un escenario maestro / detalle:
<h2>Groups</h2>
<div id="GroupList">
</div>
<div id="GroupDetail" title="Detail Group">
</div>
La lista de grupos se carga una vez en el div y hay una llamada ajax posible a un controlador para cada elemento de la lista de grupos:
<%= Ajax.ActionLink("Edit", "DetailLocalisationGroup",
new { id = group.Id },
new AjaxOptions() {
UpdateTargetId = "DetailLocalisationGroup",
OnSuccess = "InitialisationDetailGroup" })%>
que llama a esta acción DetailLocalisationGroup que debe alimentar el div GroupDetail con html.
[AcceptVerbs("POST")]
public ActionResult DetailLocalisationGroup(int id)
{
LocalisationGroup group = servicelocalisation.GetLocalisationGroup(id);
return View("DetailGroup", group);
}
Ahora hay un formulario en el div, y al presionar el botón enviar de este formulario, simplemente enviamos la información que realmente necesitamos a un controlador que luego guardaría los datos en la base de datos.
Durante todos estos eventos, la Lista de grupos se llenó con las cosas que se mostraban en la pantalla del cliente, pero no se necesitaba interacción allí, y ¿por qué molestarse con un estado visual para estos ...
MVC tiene algunas ventajas sobre WebForms, pero también tiene algunas desventajas, así como los detalles detallados en esta respuesta . Creo que la pregunta fundamental que debe hacerse es si ViewState es un problema para usted ahora, ¿es un problema tal que debe volver a escribir su solicitud? Si no es así, entonces Learning MVC es un objetivo valioso (realmente es bastante bueno) pero no es un riesgo para el que pueda hacer negocios.
Con eso dicho, ViewState puede ser deshabilitado en un número sorprendentemente grande de casos. Se utiliza principalmente para conservar el valor de los controles a través de una devolución posterior. Entonces, por ejemplo, si tiene un cuadro de texto cuyo valor debe verificar en el lado del servidor, así como un montón de otros campos, ViewState le permitirá manejar el post-back, detectar el error (y mostrar una etiqueta) y luego devolver al usuario al formulario con todas sus entradas intactas. Sin embargo, si solo se rellenará y publicará un formulario y luego lo redireccionará a otra página, puede desactivarlo de manera segura.
Finalmente, pregunta qué está haciendo la gente para evitar el estado de sesión. ¿Hay alguna razón para evitar el estado de sesión? Seguramente no querrás mucha información allí, pero evitarla por completo no es realmente necesario y, de hecho, te costará una de las herramientas más poderosas de tu arsenal.
Pero por supuesto que puede. De hecho, la web es sin estado. Cualquier pensamiento en contrario es la aberración, de hecho.
Los controles web se han ido en MVC. No hay eventos disparando en el lado del servidor. Esto se reemplaza por dos mecanismos diferentes: URL y datos de formulario de POST. El uso adecuado de estos reemplazará su necesidad de ViewState.
En una aplicación web ASP.NET convencional, colocaría un LinkButton en su página web que realizaría la función X. ASP.NET pegaría muchos elementos de ViewState cruft, javascript y otras cosas en la página web para que, cuando el usuario haga clic en el botón y "vuelve a publicar" en el sitio web (al enviar un formulario que nadie sabe que existía), ASP.NET reconstruye lo que sucedió y determina que se debe ejecutar un controlador de eventos de botones en particular.
En MVC, usted construye su enlace para acceder a una ruta en particular. La ruta describe lo que el usuario desea hacer: / Usuarios / Delincuente / Índice (muestra una lista de todos los usuarios delincuentes). El sistema de enrutamiento en MVC determina qué Controlador manejará esta ruta y qué método ejecutará en ese controlador. Cualquier información adicional se puede transmitir al método del controlador mediante valores de cadena de consulta de URL (? Página = 5 para la quinta página de delincuentes).
Además de las URL, puede usar formularios HTML para POST devolver información más compleja (como el valor de los datos de un formulario) o cosas que no caben en una cadena de consulta, como un archivo.
Así que "mantienes" el estado a través de cadenas de consulta y valores de POST. Encontrarás que, de hecho, no hay mucho estado que mantener al final. De hecho, tener que mantener muchos estados es una buena indicación de que falta el diseño o que está intentando hacer algo que no se ajusta al modelo de un sitio web.
Puede almacenar cualquier objeto en el estado de la sesión.
HttpContext.Session["userType"] = CurrentUser.GetUserType();
Puedes imitar el estado de vista con el proyecto MVC3Futures . Se guardará todo el modelo a la vista.
Todo lo que tienes que hacer es serializar el modelo y cifrarlo a la vista.
@Html.Serialize("Transfer", Model, SerializationMode.EncryptedAndSigned)
Y en el controlador agregar atributo deserializado.
public ActionResult Transfer(string id,[Deserialize(SerializationMode.EncryptedAndSigned)]Transfer transfer)
Todas las respuestas que dicen que ASP.NET MVC no usa el estado son bastante correctas. Pero ASP.NET MVC, de hecho, usa algún estado, aunque no funciona en nada como ViewState.
Por lo general, cuando alguien envía los datos a la aplicación, querrá validar los datos y mostrar un error si los datos no son válidos. Sin embargo, si acaba de devolver la página que contiene el mensaje de error inmediatamente, cuando el usuario presione F5 para volver a cargar la página, los datos se volverán a enviar. Esto no suele ser lo que quieres. Por lo tanto, cuando se da cuenta de que los datos POSTED no son válidos, desea que los usuarios obtengan la página (o quizás otra página) y muestren un mensaje de error. Lo haces devolviendo un código de estado de redirección HTTP. Sin embargo, una vez que llega la solicitud GET del usuario, ¿cómo sabe qué mensaje de error mostrar? Deberá recordar esto de alguna manera desde el momento en que (el servidor) esté manejando el POST hasta que esté manejando el GET.
Para hacer esto, utiliza una característica de ASP.NET MVC llamada TempData. En realidad, esto es solo una envoltura alrededor de la sesión, lo que garantiza que todo lo que introduzca en el diccionario TempData permanecerá allí hasta la próxima solicitud y no más.
viewstate es solo un campo de formulario grande, feo y oculto.
Escriba sus propios campos de formulario ocultos y cifrelos si es necesario.
Afortunadamente, ya no existe una forma sencilla de volcar muchos y muchos datos en la página, por lo que debe ser juicioso sobre lo que desea guardar.