MVVM ViewModel vs. MVC ViewModel

ViewModel es un término que se utiliza tanto en MVVM (Model-View-ViewModel) como en la implementación recomendada para ASP.NET MVC. Investigar “ViewModel” puede ser confuso dado que cada patrón usa el mismo término.

¿Cuáles son las principales diferencias entre MVC ViewModel y MVVM ViewModel? Por ejemplo, creo que MVVM ViewModel es más rico, dada la falta de un Controlador. ¿Es esto cierto?

Una pregunta bastante desafiante para responder sucintamente, pero lo intentaré. (Tenga en cuenta que las respuestas a este tipo de preguntas aún son tema de debate entre los desarrolladores).

En MVC, ViewModel proporciona toda la información necesaria para que se visualice una vista. La información que contiene se crea usando los datos definidos en el Modelo. La Vista lee ViewModel y representa la salida. La entrada desde la Vista se pasa al Controlador, que manipula el Modelo, construye un Modelo de Vista apropiado, y lo pasa a la Vista para su representación.

En MVVM, ViewModel cumple la misma función que en MVC, pero también reemplaza parte del controlador MVC al proporcionar comandos que permiten que la vista manipule el modelo. El enlace de datos de WPF gestiona la actualización de la Vista de acuerdo con los cambios en el Modelo de Vista (y esto reemplaza efectivamente la función restante del Controlador MVC).

Ha pasado un tiempo desde que jugué UI Design Patterns Bingo … sin embargo, déjame echar un vistazo a esto …

MVVM es algo que MS ha creado … porque lo ayuda a aprovechar al máximo WPF. Combina el estado y el comportamiento de la vista en una clase (un modelo de presentación) que es fácilmente comprobable + y luego utiliza el enlace de datos para obtener los datos en cualquier vista.

Este enlace tiene un resumen de la evolución de MVVM. Combine esto con la serie ” Arquitecturas GUI ” de Fowler, y debería estar en camino.

Actualización: No sabía que había algo llamado MVC-VM . Aparentemente una idea original de la multitud ASP.NET MVC. Se ve y suena similar a MVVM (excepto afinado para ASP.NET MVC); la única diferencia es que impone una restricción de que existe una asignación 1: 1 entre VM y View. Hubiera adivinado 1: N, pero todo lo demás coincide.

Sé que esta es una (antigua) pregunta, pero me han señalado como un ejemplo del uso de “Ver modelo” en el contexto de MVC. Yo sostengo que esto es incorrecto y puede llevar a la confusión de las personas que son nuevas en los patrones de uno o ambos. Quien lo está haciendo, stahp. Aquí está el por qué (e incluso es una respuesta a la pregunta original de una manera indirecta).

Un ejemplo de cuándo sucede esto se puede ver en esta pregunta . El usuario está tratando de usar un modelo de vista que implementa INotifyPropertyChanged en una aplicación ASP.NET MVC, combinando así el diseño de aplicaciones web de escritorio y sin estado en un error arquitectónico y desgarro.

Para decirlo simplemente, no hay “Ver modelo” en el patrón MVC. Sin embargo, hay un equivalente funcional, y ese es el controlador. Para ser claros acerca de las partes y sus propósitos,

MVVM (aplicaciones de escritorio):

  • Modelo – Objeto fuertemente tipado que contiene los datos que se pasarán entre la Vista y el Modelo de Vista
  • Ver : la interfaz de usuario vista por el usuario y a través de la cual el usuario interactúa con el sistema
  • Ver modelo – Interpreta las acciones del usuario (por ejemplo, a través de ICommand), las realiza, actualiza el estado de la aplicación

MVC (aplicaciones web):

  • Modelo – Objeto fuertemente tipado * que contiene los datos que se transmitirán entre la Vista y el Modelo de visualización
  • Ver : un generador de IU que combina el modelo, el código y el HTML para renderizar una página web
  • Controlador : acepta las solicitudes de los usuarios, las interpreta, actualiza el estado de la aplicación y utiliza una vista para convertir este estado en una página web HTML.

El modelo es prácticamente el mismo en ambos patrones. Los modelos de escritorio pueden implementar notificaciones de eventos de actualización, los modelos web pueden ser dynamics (es decir, no estar fuertemente tipados), y ambos pueden incluir o no métodos de validación o metadatos.

La Vista en el escritorio es lo que ve el usuario. En la web, es un generador que genera HTML para que los navegadores lo muestren en el lado del cliente. Debe interpretar la interacción del usuario en el escritorio, pero en la web que se maneja mediante javascript del lado del cliente, el navegador y las solicitudes que se envían al servidor.

El modelo / controlador de vista son aproximadamente equivalentes funcionalmente, pero difieren mucho en cómo se implementan y cómo funcionan. En el Modelo de Vista , la interacción del usuario con la aplicación se transfiere a Ver Modelos a través de ICommands, eventos enrutados y otros métodos (muchos frameworks MVVM proporcionan diferentes formas de enganchar Modelos de Vista a la UI y otras partes de la aplicación). En un controlador , aparece una solicitud con toda la información necesaria para que el controlador devuelva un resultado al usuario (suponiendo que sea una solicitud de 200 OK). El Controlador debe realizar cualquier trabajo que sea necesario para crear el estado (también conocido como Modelo) necesario para el generador HTML (la Vista) para crear la respuesta. Desde el punto de vista del diseño, el Controlador se encuentra sobre la Vista y el Modelo conociendo y controlando ambos, mientras que el Modelo de Vista se ubica al lado de la Vista, pasando el Modelo (y otra información) entre ellos.

Lo que realmente parece confundir a algunas personas es que hay marcos MVVM del lado del cliente que puede mezclar en su aplicación MVC. Estos existen únicamente en javascript en el navegador del usuario, y no tienen nada que ver con el patrón particular que está siguiendo en el lado del servidor. Puede ejecutar un sitio web ASP clásico que usa MVVM en el lado del cliente. Demonios, puedes ejecutar páginas HTML estáticas que usan MVVM en el lado del cliente. Ellos son eso separados.

Estos marcos javascript MVVM generalmente siguen un patrón similar al patrón MVVM de escritorio descrito anteriormente, pero ajustado para trabajar más en sintonía con la naturaleza del HTML DOM y javascript. Por ejemplo, no existe un sistema de enlace extenso entrelazado en el DOM, y javascript tiene un sistema de tipo muy limitado, por lo que emparejar plantillas a modelos es muy diferente que en WPF. También suelen funcionar desconectados del servidor, y cuando necesitan interactuar, prefieren las llamadas AJAX en lugar de POSTear la página de vuelta al Controlador (las llamadas AJAX normalmente las manejan los Controladores WebAPI en ASP.NET MVC).

Entonces, para resumir, realmente no hay un Modelo de Vista en MVC. El controlador es el equivalente aproximado, pero es muy diferente en cuanto a cómo recibe la entrada del usuario, la interpreta y devuelve un resultado al usuario. Usar el término “Ver modelo” para referirse a cualquier cosa en MVC solo puede generar confusión y, por lo tanto, debe evitarse. Use los términos apropiados para las partes apropiadas del patrón. Puede parecer pedante, pero debería ayudar a mantener las cosas claras y ser menos confuso para las personas que son nuevas en ambos patrones.