View Models

Es un patrón que nos permite separar el modelo de la interface de usuario.
Desde mi muy particular punto de vista un ViewModel es una forma de organizar los datos que pertenecen a un modelo para que puedan ser presentados sin tener que exponer la entidad, incluso aun que dicha entidad no exista en la base de datos.

En nuestro Blog, un ViewModel es una clase especial que se crea para enviar los datos al view y que le permite al Controler realizar un automatic binding al momento de recibir la respuesta del usuario, a través del envió de la información.

 

Analicemos porque existe?

Según el patrón las entidades pertenecen al MODEL y contienen propiedades que pueden estar relacionadas a campos en la base de datos o simplemente ser propiedades que no existen en la base de datos y que sirven para la lógica de la aplicación. Entonces cuando debemos enviar los datos al view para que a su vez se puedan enviar al usuario por medio del view, puede resultar pesado enviar una entidad del MODEL donde hay información de más. Otro punto que no debemos perder de vista es que las entidades que estamos usando pueden ser objetos generados por alguna herramienta como el Entity Framework.
Eso no es todo, para que resulte más complejo, cuando estamos creando un view resulta que se deben enviar algunos datos que ni son de la base de datos, ni son propiedades para uso de la lógica…o sea solo son propiedades que deben existir en ese momento y no tiene sentido para nadie más.

 

Complejo no?

En realidad podemos simplificar esta explicación, pensando que un ViewModel sirve para el envió de los datos necesarios entre el Controler y el view. La estructura del ViewModel está relacionada con la estructura del view. O sea es una representación en clases de la interface.

Por ejemplo:

Imaginen que tenemos una entidad compleja: Una pregunta y sus respuestas. Y necesitamos enviar estos datos al view para que se presente.

Si observan con detenimiento podrán ver que en la entidad Reactivo hay algunas propiedades que son Llaves foráneas: EmpresaId, CategoriaId, SubcategriaId, NivelId. Si queremos que el usuario pueda seleccionar estos valores, desde combos, entonces sería necesario enviar los catálogos correspondientes. En la entidad Reactivo no hay donde poner esto información para que sea usada al momento de crear la View.
Es en este momento que usar un ViewModel tiene sentido, porque podemos crear una clase que sea la representación de la interface y que tenga alguna propiedad donde podamos agregar lo que se necesite.

Si revisamos el código podemos ver que justo después de cada una de las propiedades que comentamos, hay una propiedad de tipo LIST que puede recibir el catalogo relacionado.

 

Como usarlo?

En el Controler necesitamos un método privado para cargar desde el repositorio relacionado los catálogos. Creamos la instancia del ViewModel y se lo enviamos al View.

Esto nos permite establecer esta estructura al momento de crear un View, como el tipo que debemos enviarle.
Esto puede ser verificado en la primera línea del View.

En esta línea se establece el tipo del MODEL que se empleara al llenar los controles.
Cuando el cliente realiza un post de su respuesta esta se recibe en la acción apropiada y se realiza el automatic binding. MVC nos ofrece una forma de verificar que dicho mapeo se haya realizado adecuadamente.

Espero que con este ejemplo, haya quedado demostrada la utilidad de estas clases en el manejo de la información.