Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

10 años online 🎂

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
martes, 6 de julio de 2010
ASP.NET MVC Esta cuestión, lanzada por un amigo de Variable not found en Facebook, comenzaba un pequeño e interesante debate hace unos días, tras la publicación del enlace al post Persisting model state in ASP.NET MVC using Serialize HTMLHelper, en el que se describía la posibilidad de mantener el estado entre peticiones utilizando un mecanismo similar al infame ViewState de Webforms.

Esta herramienta, como otras muchas, se encuentra en el proyecto MvcFutures, un ensamblado distribuido a través de CodePlex, que ha sido creado por el mismo equipo del framework MVC para experimentar nuevas características y funcionalidades futuras del producto.

Su funcionamiento es muy sencillo. Imaginemos el siguiente controlador, que envía a la vista un objeto de tipo User:

public ActionResult Prueba()
{
    return View("MiVista", new User
                                {
                                    Nombre = "José",
                                    FechaNacimiento = DateTime.Now,
                                    Email = "micorreo@correo.com",
                                    Pais = "España",
                                    Provincia = "Sevilla"
                                });
}

Desde la vista correspondiente podemos serializar el objeto del Modelo cuyo estado nos interese preservar, como en el siguiente ejemplo, en el que hacemos persistir las propiedades del objeto User almacenado en la propiedad  Model de la vista:

<% using (Html.BeginForm()) { %>
    <%= Html.Serialize("Userdata", Model) %>
    ... (resto del formulario)
<% } %>

Y ya desde la acción receptora de los datos del formulario, para volver a materializar el objeto serializado bastaría con incluirlo como parámetro de la misma, decorándolo con el atributo [Deserialize] de la siguiente forma:

[HttpPost]
public ActionResult Prueba([Deserialize]User userData, ... ) // Otros parámetros recibidos
{
    // ...
}

Como de costumbre, el nombre del parámetro de la acción debe coincidir con el asignado al campo oculto donde se ha almacenado la información, que coincide con el identificador que hemos indicado ("Userdata") en la llamada al helper en la vista.

El único requisito fundamental para poder obrar esta magia es que la clase y todas sus propiedades sean serializables, como la siguiente:

[Serializable]
public class User
{
    public string Nombre { get; set; }
    public DateTime FechaNacimiento { get; set; }
    public string Pais { get; set; }
    public string Provincia { get; set; }
    public string Email { get; set; }
    public string FacebookUser { get; set; }
    public string TwitterUser { get; set; }
}

¿Y cómo ve ve esto en tiempo de ejecución? El resultado será algo como el siguiente, donde podemos apreciar un cierto tufillo a ViewState:

<form action="/user/prueba" id="form0" method="post">
    <input name="userData" type="hidden" 
        value="/wEy6QIAAQAAAP////8BAAAAAAAAAAwCAAAATk12Y0Z1dHVyZXNTZXJp />
              YWxpemF0aW9uLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhb
              CwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAI012Y0Z1dHVyZXNTZXJpYW
              xpemF0aW9uLk1vZGVscy5Vc2VyBwAAABc8Tm9tYnJlPmtfX0JhY2tpbmd
              GaWVsZCA8RmVjaGFOYWNpbWllbnRvPmtfX0JhY2tpbmdGaWVsZBU8UGFp
              cz5rX19CYWNraW5nRmllbGQaPFByb3ZpbmNpYT5rX19CYWNraW5nRmllb
              GQWPEVtYWlsPmtfX0JhY2tpbmdGaWVsZB08RmFjZWJvb2tVc2VyPmtfX0
              JhY2tpbmdGaWVsZBw8VHdpdHRlclVzZXI+a19fQmFja2luZ0ZpZWxkAQA
              BAQEBAQ0CAAAACgAAAAAAAAAACgoKCgoL"
    ... (resto del formulario)
</form>

Por defecto, el contenido del objeto se volcará en la página utilizando codificación Base64, aunque esto puede modificarse utilizando la sobrecarga del helper Serialize() que permite indicar el tipo de serialización (SerializationMode) a emplear, eligiéndola entre texto plano (por defecto, PlainText o Base64), cifrada, firmada, o firmada y cifrada.

En cualquier caso, se trata de agregar un chorizo de cierto volumen a la página, que la hará más pesada y afectará al rendimiento de nuestro sistema, sobre todo si el objeto que queremos hacer persistir es complejo, por lo que podría pensarse…

¿Estamos trayendo de nuevo el fantasma del ViewState a las aplicaciones MVC?

En mi opinión, no. Y si bien es cierto que estamos utilizando una técnica parecida al ViewState para conservar el estado de objetos, no creo que sea un mal comparable.

El ViewState en Webforms no es una opción si realmente queremos sacar provecho de su potencia; si lo eliminamos totalmente, dejaríamos Webforms como un ASP clásico con esteroides ;-). Aunque ASP.NET 4 ha mejorado mucho el control sobre éste, sigue siendo necesario su uso para mantener el estado de la vista y dar soporte al modelo stateful de esta tecnología.

En ASP.NET MVC, la persistencia de un objeto completo en la página es un caso excepcional; no se me ocurren muchos escenarios en los que pueda sernos útil, y ninguno donde sea la única solución existente. Por ejemplo, si tenemos un proceso que el usuario debe realizar en varios pasos, u otro escenario en el que debamos mantener el estado del Modelo, está claro que debemos hacerlo persistir de algún modo, ya sea en cliente o en servidor.

Como comentaba el amigo Eduard Tomás hace unos días, utilizar variables de sesión no es siempre la mejor opción, y a veces hay que recurrir al cliente para almacenar cierta información. Imaginemos, por ejemplo, un asistente para el registro de usuarios en una comunidad on-line; si realmente no nos interesa almacenar dato alguno en el servidor hasta que el usuario confirme su registro en el último paso, una posibilidad bastante interesante sería delegar el almacenamiento temporal, la información introducida en cada uno de los pasos del asistente, a la capa cliente.

Aún en este escenario, el uso de la serialización de MvcFutures es totalmente opcional. De hecho, es perfectamente posible conseguir el mismo efecto introduciendo manualmente las propiedades de los objetos en campos hidden individuales, y recuperándolas posteriormente desde el controlador  utilizando el Model Binder. Sin embargo, cuando el objeto sea complejo, el helper Serialize() puede ahorrarnos muchas pulsaciones de tecla y evitar errores, aunque sea a costa de aumentar el peso de la página (imaginemos un objeto compuesto a su vez por otros, o colecciones).

En lo que seguro que estamos totalmente de acuerdo, como siempre ocurre en estos casos, es en la necesidad de aplicar el sentido común y prudencia en su uso. Antes de utilizar esta técnica hay que tener en cuenta el peso adicional que vamos a añadir a las páginas; asimismo, desde el punto de vista de la seguridad, siempre tener en mente que la información almacenada en cliente es fácilmente manipulable.

Publicado en: Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

Aún no hay comentarios, ¡sé el primero!