in

asp.net mvc – ¿Qué es ViewModel en MVC?

apple touch icon@2

Editar: actualicé esta respuesta en mi blog:

http://www.samwheat.com/post/The-function-of-ViewModels-in-MVC-web-development

Mi respuesta es un poco larga, pero creo que es importante comparar los modelos de vista con otros tipos de modelos de uso común para comprender por qué son diferentes y por qué son necesarios.

Para resumir y responder directamente a la pregunta que se hace:

En términos generales, un modelo de vista es un objeto que contiene todas las propiedades y métodos necesarios para representar una vista. Las propiedades del modelo de vista a menudo están relacionadas con objetos de datos como clientes y pedidos y, además, también contienen propiedades relacionadas con la página o la aplicación en sí, como el nombre de usuario, el nombre de la aplicación, etc. Los modelos de vista proporcionan un objeto conveniente para pasar a una representación. motor para crear una página HTML. Una de las muchas razones para utilizar un modelo de vista es que los modelos de vista proporcionan una forma de realizar pruebas unitarias en determinadas tareas de presentación, como el manejo de la entrada del usuario, la validación de datos, la recuperación de datos para su visualización, etc.

A continuación, se muestra una comparación de los modelos de entidad (también conocidos como modelos DTO), modelos de presentación y modelos de vista.

Objetos de transferencia de datos también conocidos como «Modelo»

Un objeto de transferencia de datos (DTO) es una clase con propiedades que coinciden con un esquema de tabla en una base de datos. Los DTO reciben su nombre por su uso común para transportar datos desde y hacia un almacén de datos.
Características de los DTO:

  • Son objetos comerciales: su definición depende de los datos de la aplicación.
  • Por lo general, solo contienen propiedades, sin código.
  • Se utiliza principalmente para transportar datos hacia y desde una base de datos.
  • Las propiedades coinciden exacta o estrechamente con los campos de una tabla específica en un almacén de datos.

Las tablas de bases de datos suelen estar normalizadas, por lo que las DTO también suelen estar normalizadas. Esto los hace de uso limitado para presentar datos. Sin embargo, para ciertas estructuras de datos simples, a menudo funcionan bastante bien.

A continuación, se muestran dos ejemplos de cómo podrían verse los DTO:

public class Customer
{
    public int ID { get; set; }
    public string CustomerName { get; set; }
}


public class Order
{
    public int ID { get; set; }
    public int CustomerID { get; set; }
    public DateTime OrderDate { get; set; }
    public Decimal OrderAmount { get; set; }
}

Modelos de presentación

Un modelo de presentación es un utilidad clase que se utiliza para representar datos en una pantalla o informe. Los modelos de presentación se utilizan normalmente para modelar estructuras de datos complejas que se componen de datos de varios DTO. Los modelos de presentación a menudo representan una vista desnormalizada de datos.

Características de los modelos de presentación:

  • Son objetos comerciales: su definición depende de los datos de la aplicación.
  • Contienen principalmente propiedades. El código generalmente se limita a formatear datos o convertirlos ao desde un DTO. Los modelos de presentación no deben contener lógica empresarial.
  • A menudo presentan una vista desnormalizada de datos. Es decir, a menudo combinan propiedades de varios DTO.
  • A menudo contienen propiedades de un tipo base diferente al de un DTO. Por ejemplo, las cantidades en dólares se pueden representar como cadenas para que puedan contener comas y un símbolo de moneda.
  • A menudo se definen por cómo se utilizan, así como por las características de sus objetos. En otras palabras, un DTO simple que se utiliza como modelo de respaldo para renderizar una cuadrícula es de hecho también un modelo de presentación en el contexto de esa cuadrícula.

Los modelos de presentación se utilizan «según sea necesario» y «donde sea necesario» (mientras que los DTO suelen estar vinculados al esquema de la base de datos). Se puede usar un modelo de presentación para modelar datos para una página completa, una cuadrícula en una página o un menú desplegable en una cuadrícula en una página. Los modelos de presentación suelen contener propiedades que son otros modelos de presentación. Los modelos de presentación a menudo se construyen con un propósito de un solo uso, como representar una cuadrícula específica en una sola página.

Un modelo de presentación de ejemplo:

public class PresentationOrder
{
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Ver modelos

Un modelo de vista es similar a un modelo de presentación en que es una clase de respaldo para representar una vista. Sin embargo, es muy diferente de un modelo de presentación o un DTO en cómo se construye. Los modelos de vista a menudo contienen las mismas propiedades que los modelos de presentación y los DTO y, por esta razón, a menudo se confunden entre sí.

Características de los modelos de vista:

  • Son la única fuente de datos que se utiliza para representar una página o pantalla. Por lo general, esto significa que un modelo de vista expondrá todas las propiedades que cualquier control de la página necesitará para representarse correctamente. Hacer que el modelo de vista sea la única fuente de datos para la vista mejora en gran medida su capacidad y valor para las pruebas unitarias.
  • Están objetos compuestos que contienen propiedades que constan de datos de la aplicación, así como propiedades que utiliza el código de la aplicación. Esta característica es crucial al diseñar el modelo de vista para su reutilización y se analiza en los ejemplos siguientes.
  • Contiene el código de la aplicación. Los modelos de vista generalmente contienen métodos que se llaman durante la renderización y cuando el usuario está interactuando con la página. Este código generalmente se relaciona con el manejo de eventos, la animación, la visibilidad de los controles, el estilo, etc.
  • Contienen código que llama a servicios comerciales con el fin de recuperar datos o enviarlos a un servidor de base de datos. Este código a menudo se coloca por error en un controlador. Llamar a los servicios comerciales desde un controlador generalmente limita la utilidad del modelo de vista para las pruebas unitarias. Para ser claros, los modelos de visualización en sí mismos no deben contener lógica empresarial, sino que deben realizar llamadas a servicios que sí contienen lógica empresarial.
  • A menudo contienen propiedades que son otros modelos de vista para otras páginas o pantallas.
  • Se escriben «por página» o «por pantalla». Por lo general, se escribe un modelo de vista único para cada página o pantalla de una aplicación.
  • Por lo general, derivan de una clase base, ya que la mayoría de las páginas y pantallas comparten propiedades comunes.

Ver composición del modelo

Como se indicó anteriormente, los modelos de vista son objetos compuestos en el sentido de que combinan las propiedades de la aplicación y las propiedades de los datos comerciales en un solo objeto. Ejemplos de propiedades de aplicación de uso común que se utilizan en modelos de vista son:

  • Propiedades que se utilizan para mostrar el estado de la aplicación, como mensajes de error, nombre de usuario, estado, etc.
  • Propiedades utilizadas para dar formato, mostrar, estilizar o animar controles.
  • Propiedades utilizadas para el enlace de datos, como objetos de lista y propiedades que contienen datos intermedios introducidos por el usuario.

Los siguientes ejemplos muestran por qué la naturaleza compuesta de los modelos de vista es importante y cómo podemos construir mejor un modelo de vista tan eficiente y reutilizable.

Supongamos que estamos escribiendo una aplicación web. Uno de los requisitos del diseño de la aplicación es que el título de la página, el nombre de usuario y el nombre de la aplicación deben aparecer en todas las páginas. Si queremos crear una página para mostrar un objeto de orden de presentación, podemos modificar el modelo de presentación de la siguiente manera:

public class PresentationOrder
{
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Este diseño puede funcionar … pero ¿qué pasa si queremos crear una página que muestre una lista de pedidos? Las propiedades PageTitle, UserName y ApplicationName se repetirán y será difícil de manejar. Además, ¿qué pasa si queremos definir alguna lógica a nivel de página en el constructor de la clase? Ya no podemos hacer eso si creamos una instancia para cada pedido que se mostrará.

Composición sobre herencia

Aquí hay una forma en que podemos volver a factorizar el modelo de presentación de pedidos de modo que se convierta en un modelo de vista real y sea útil para mostrar un solo objeto PresentationOrder o una colección de objetos PresentationOrder:

public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public PresentationOrder Order { get; set; }
}


public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

Al observar las dos clases anteriores, podemos ver que una forma de pensar en un modelo de vista es que es un modelo de presentación que contiene otro modelo de presentación como propiedad. El modelo de presentación de nivel superior (es decir, el modelo de vista) contiene propiedades que son relevantes para la página o aplicación, mientras que el modelo de presentación (propiedad) contiene propiedades que son relevantes para los datos de la aplicación.

Podemos llevar nuestro diseño un paso más allá y crear una clase de modelo de vista base que se puede usar no solo para PresentationOrders sino también para cualquier otra clase:

public class BaseViewModel
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
}

Ahora podemos simplificar nuestro PresentationOrderVM así:

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public PresentationOrder Order { get; set; }
}

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

Podemos hacer que nuestro BaseViewModel sea aún más reutilizable haciéndolo genérico:

public class BaseViewModel<T>
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business property
    public T BusinessObject { get; set; }
}

Ahora nuestras implementaciones son sencillas:

public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
    // done!
}

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

jcl

Tutorial de JCL

4025db7f6707e44ef8e67c04e16afd40 1200 80

30 películas donde todos mueren al final