¿Cuál es la diferencia entre MVC y MVVM?
¿Existe alguna diferencia entre el patrón estándar "Modelo Vista Controlador" y el patrón Modelo/Vista/VerModelo de Microsoft?
MVC/MVVM no es una opción .
Los dos patrones surgen, de diferentes maneras, tanto en el desarrollo ASP.Net como en Silverlight/WPF.
Para ASP.Net, MVVM se utiliza para vincular datos bidireccionalmente dentro de las vistas. Suele ser una implementación del lado del cliente (por ejemplo, utilizando Knockout.js). MVC, por otro lado, es una forma de separar las preocupaciones en el lado del servidor .
Para Silverlight y WPF, el patrón MVVM es más amplio y puede parecer que actúa como un reemplazo de MVC (u otros patrones de organización de software en responsabilidades separadas). Una suposición, que frecuentemente surgía de este patrón, era que ViewModelsimplemente reemplazaban el controlador MVC(como si pudieras simplemente sustituirlo VMen Cel acrónimo y todo sería perdonado)...
ViewModel no necesariamente reemplaza la necesidad de controladores separados.
El problema es: que para ser comprobable de forma independiente*, y especialmente reutilizable cuando sea necesario, un modelo de vista no tiene idea de qué vista lo muestra, pero, lo que es más importante, no tiene idea de de dónde provienen sus datos .
*Nota: en la práctica, los controladores eliminan la mayor parte de la lógica del ViewModel que requiere pruebas unitarias. La máquina virtual se convierte entonces en un contenedor tonto que requiere pocas pruebas, si es que requiere alguna. Esto es bueno ya que la VM es solo un puente entre el diseñador y el codificador, por lo que debe mantenerse simple.
Incluso en MVVM, los controladores normalmente contendrán toda la lógica de procesamiento y decidirán qué datos mostrar en qué vistas utilizando qué modelos de vista.
Por lo que hemos visto hasta ahora, el principal beneficio del patrón ViewModel es eliminar código del código subyacente XAML para hacer que la edición de XAML sea una tarea más independiente . Seguimos creando controladores, cuando sea necesario, para controlar (sin juego de palabras) la lógica general de nuestras aplicaciones.
Las pautas básicas de MVCVM que seguimos son:
- Las vistas muestran una determinada forma de datos . No tienen idea de dónde provienen los datos.
- Los ViewModels tienen una determinada forma de datos y comandos , no saben de dónde provienen los datos o el código ni cómo se muestran.
- Los modelos contienen los datos reales (varios contextos, almacenamiento u otros métodos)
- Los controladores escuchan y publican eventos. Los controladores proporcionan la lógica que controla qué datos se ven y dónde. Los controladores proporcionan el código de comando a ViewModel para que ViewModel sea realmente reutilizable.
También notamos que el marco de generación de código de Sculpture implementa MVVM y un patrón similar a Prism Y también hace un uso extensivo de controladores para separar toda la lógica de casos de uso.
No asuma que los controladores quedan obsoletos debido a los modelos de vista.
He comenzado un blog sobre este tema que agregaré cuando pueda (archivar solo porque se perdió el alojamiento) . Hay problemas al combinar MVCVM con los sistemas de navegación comunes, ya que la mayoría de los sistemas de navegación solo usan Vistas y VM, pero hablaré de eso en artículos posteriores.
Un beneficio adicional de utilizar un modelo MVCVM es que sólo los objetos del controlador necesitan existir en la memoria durante la vida útil de la aplicación y los controladores contienen principalmente código y pocos datos de estado (es decir, una pequeña sobrecarga de memoria). Esto hace que las aplicaciones consuman mucha menos memoria que las soluciones en las que se deben conservar los modelos de vista y es ideal para ciertos tipos de desarrollo móvil (por ejemplo, Windows Mobile que utiliza Silverlight/Prism/MEF). Por supuesto, esto depende del tipo de aplicación, ya que es posible que aún necesite conservar las máquinas virtuales en caché ocasionales para mejorar la capacidad de respuesta.
Nota: Esta publicación ha sido editada numerosas veces y no se centró específicamente en la pregunta específica formulada, por lo que actualicé la primera parte para cubrirla también. Gran parte de la discusión, en los comentarios a continuación, se relaciona únicamente con ASP.Net y no con el panorama más amplio. Esta publicación tenía como objetivo cubrir el uso más amplio de MVVM en Silverlight, WPF y ASP.Net y tratar de disuadir a las personas de reemplazar controladores con ViewModels.
Creo que la forma más sencilla de entender lo que se supone que significan estas siglas es olvidarse de ellas por un momento. En su lugar, piense en el software con el que se originó cada uno de ellos. Realmente se reduce simplemente a la diferencia entre la web inicial y el escritorio.
A medida que crecieron en complejidad a mediados de la década de 2000, el patrón de diseño de software MVC, que se describió por primera vez en la década de 1970, comenzó a aplicarse a las aplicaciones web. Piense en bases de datos, páginas HTML y código intermedio. Refinemos esto un poco para llegar a MVC: Para »base de datos«, supongamos que la base de datos más el código de interfaz. Para »páginas HTML«, supongamos plantillas HTML más código de procesamiento de plantillas. Para el "código intermedio", supongamos que el código asigna los clics del usuario a las acciones, lo que posiblemente afecte la base de datos y definitivamente cause que se muestre otra vista. Eso es todo, al menos a los efectos de esta comparación.
Mantengamos una característica de este material web, no como es hoy, sino como existía hace diez años, cuando JavaScript era una molestia humilde y despreciable, que los verdaderos programadores hicieron bien en evitar: la página HTML es esencialmente tonta y pasiva. . El navegador es un cliente ligero o, si se prefiere, un cliente deficiente. No hay inteligencia en el navegador. Regla de recargas de página completa. La »vista« se genera de nuevo cada vez.
Recordemos que este modo web, a pesar de estar de moda, estaba terriblemente atrasado respecto al escritorio. Las aplicaciones de escritorio son clientes gordos o clientes ricos, por así decirlo. (Incluso un programa como Microsoft Word puede considerarse como una especie de cliente, un cliente para documentos). Son clientes llenos de inteligencia, llenos de conocimiento sobre sus datos. Son con estado. Almacenan en caché los datos que están manejando en la memoria. No hay tanta mierda como recargar la página completa.
Y esta rica forma de escritorio es probablemente donde se originó el segundo acrónimo, MVVM. No os dejéis engañar por las letras, por la omisión de la C. Los controladores siguen ahí. Tienen que serlo. No se elimina nada. Solo agregamos una cosa: estado, datos almacenados en caché en el cliente (y junto con inteligencia para manejar esos datos). Esos datos, esencialmente un caché en el cliente, ahora se llaman »ViewModel«. Es lo que permite una rica interactividad. Y eso es.
- MVC = modelo, controlador, vista = comunicación esencialmente unidireccional = interactividad deficiente
- MVVM = modelo, controlador, caché, vista = comunicación bidireccional = rica interactividad
Podemos ver que con Flash, Silverlight y, lo más importante, JavaScript, la web ha adoptado MVVM. Los navegadores ya no pueden llamarse legítimamente clientes ligeros. Mire su programabilidad. Mire su consumo de memoria. Observe toda la interactividad de Javascript en las páginas web modernas.
Personalmente, encuentro que esta teoría y este acrónimo son más fáciles de entender si observamos a qué se refiere en la realidad concreta. Los conceptos abstractos son útiles, especialmente cuando se demuestran sobre temas concretos, por lo que la comprensión puede cerrar el círculo.
MVVM Model-View ViewModel es similar a MVC, Model-View Controller
El controlador se reemplaza con un ViewModel . El ViewModel se encuentra debajo de la capa UI. ViewModel expone los datos y los objetos de comando que la vista necesita. Podría pensar en esto como un objeto contenedor del que la vista obtiene sus datos y acciones. ViewModel extrae sus datos del modelo.
Russel East hace un blog que analiza más detalladamente por qué MVVM es diferente de MVC.
