ASP.NET Modelo MVC vs ViewModel

En el más simple de los términos, me gusta pensar en lo siguiente:

Modelo: Estrictamente se ve y se siente como su modelo de datos. A todos los efectos, es solo una representación de clase de su modelo de datos. No tiene conocimiento de su Punto de Vista ni de ningún elemento dentro de su Punto de Vista. Dicho esto, no debe contener ningún atributo decoradores (ie; Requerido, Longitud, etc.).) que usarías para tu Vista.

Modelo de vista: Sirve como un aglutinante de datos entre su vista y su Modelo y en muchos casos, es también una envoltura para su Modelo. Se volvería inútil sin la vista, por lo que normalmente no es reutilizable en varias Vistas y Controladores como lo es un Modelo estándar.

Como ejemplo, su Modelo puede tener las siguientes propiedades, que son representaciones directas de su fuente de datos:

    public string FirstName { get; set; }
    public string LastName { get; set; }

Ahora, dado que su Modelo de vista está vinculado a su vista, puede tener la siguiente propiedad, que concatena el campo FirstName y LastName del Modelo campo juntos como una cadena:

    [Display(Name = "Customer Name")]                
    public string CustomerFullName { get { return String.Format("{0} {1}", myModel.FirstName, myModel.LastName) }}

Este artículo me pareció un recurso muy útil para comprender cómo interactúan el "Modelo de Dominio" y el "Modelo de Vista" dentro de una aplicación MVC, particularmente en lo que respecta al enlace. Lo mejor de todo incluye ejemplos en lugar de descripciones abstractas.

"Desde que MVC ha sido lanzado, he observado mucha confusión sobre la mejor manera de construir modelos de vista. A veces esta confusión no está exenta de una buena razón, ya que no parece haber un montón de información sobre las mejores prácticas recomendaciones. Además, no hay una solución" única para todos " que actúe como la bala de plata. En este post, describiré algunos de los principales patrones que han surgido y los pros/contras de cada uno. Es importante tener en cuenta que muchos de estos patrones han surgido de personas que resuelven problemas del mundo real."

Http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

WikiPedia tiene una descripción más completa de Model vs. ModelView que la que obtendrás en una respuesta SO: http://en.wikipedia.org/wiki/Model_View_ViewModel

Cito:

Modelo : como en el patrón MVC clásico, el modelo se refiere a (a) un modelo de objeto que representa el contenido de estado real (un enfoque orientado a objetos), o (b) la capa de acceso a datos que representa ese contenido (un enfoque centrado en datos).

Ver: como en el MVC clásico patrón, la vista se refiere a todos los elementos mostrados por la GUI, como botones, ventanas, gráficos y otros controles.

ViewModel : el ViewModel es un "Modelo de la Vista", lo que significa que es una abstracción de la Vista que también sirve como enlace de datos entre la Vista y el Modelo. Podría verse como un aspecto especializado de lo que sería un Controlador (en el patrón MVC) que actúa como un aglutinante/convertidor de datos que cambia la información del modelo en Información de vista y pasa comandos de la Vista al Modelo. El ViewModel expone propiedades públicas, comandos y abstracciones. El ViewModel se ha comparado con un estado conceptual de los datos en oposición al estado real de los datos en el Modelo.

Existe una noción de ViewModel, pero generalmente no está asociada con Asp.net MVC. MVC utiliza el patrón de Controlador de Vista de modelo, donde el controlador maneja las interacciones, acumula datos del Modelo y luego pasa esos datos a la vista para su visualización.

ViewModels (y el patrón ViewModel de la vista del modelo) se asocia más generalmente con Silverlight y WPF. Xaml es un poco diferente en que las vistas pueden hacer enlace bidireccional a los ViewModels, por lo que la tecnología es un poco diferente. Por ejemplo, si vincula un cuadro de texto a un campo, a medida que escribe en ese cuadro de texto, el valor del campo se actualiza dinámicamente. Este tipo de interacción no es realmente posible en las páginas web, ya que las páginas web son apátridas.

La similitud en los dos patrones es que ambos están tratando de separar la lógica de la pantalla. El uso/razón más común para esto es testing: desea poder realizar desde el código (a través de un marco de prueba) todas las interacciones que un usuario invocar a través de la interfaz de usuario.