¿Cuál es la diferencia entre MVC y MVVM? [cerrado]


1312

¿Hay alguna diferencia entre el patrón estándar "Modelo de controlador de vista" y el modelo de Modelo / Vista / Modelo de vista de Microsoft?


55
Tenga en cuenta que aunque MVVM fue acuñado por Microsoft, muchos desarrolladores y proyectos que no son de Microsoft han comenzado a adoptar este patrón. Este comentario fue traído a usted por el departamento de odiadores de MS.
BoltClock

1
Después de haber trabajado con MVVM durante mucho tiempo, mi primer contacto con MVC fue frustrante, hasta que supe que podía pasar ViewModels de un lado a otro del navegador utilizando técnicas de enlace que se encuentran en MVVM. Pero como dijo Joel anteriormente, la única forma de recuperar el estado del navegador es publicando los cambios en un formulario (que usa pares de nombre / valor). Si no entiendes bien este punto. Tendrás dificultades en MVC. Simplemente mire el controlador como un inyector de dependencia para la vista y ya está todo listo.
John Peters

2
Una pregunta tan votada sobre los [patrones de diseño] de alto nivel. Me gustaría sugerir el uso de diagramas en las respuestas.
Ricardo

44
Aquí hay una versión archivada del artículo de Joel: web.archive.org/web/20150219153055/http://joel.inpointform.net/…
Tereza Tomcova

1
A diferencia del método MVC, ViewModel no es un controlador. En cambio, actúa como una carpeta que une datos entre la vista y el modelo. Mientras que el formato MVC está diseñado específicamente para crear una separación de preocupaciones entre el modelo y la vista, el formato MVVM con enlace de datos está diseñado específicamente para permitir que la vista y el modelo se comuniquen directamente entre sí. hackernoon.com/…
blueray

Respuestas:


684

MVC / MVVM no es una opción u otra.

Los dos patrones surgen, de diferentes maneras, en el desarrollo de ASP.Net y Silverlight / WPF.

Para ASP.Net, MVVM se utiliza para enlazar datos bidireccionales dentro de las vistas. Esta suele ser una implementación del lado del cliente (por ejemplo, usando 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 para MVC (u otros patrones de organización del software en responsabilidades separadas). Una de las hipótesis, que con frecuencia estuvo fuera de este patrón, fue que el ViewModelsimplemente se sustituye el controlador en MVC(como si sólo pudiera sustituir VMpor Cen sus siglas inglesas y todos serían perdonados) ...

ViewModel no reemplaza necesariamente 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 está mostrando, pero lo más importante es que no tiene idea de dónde provienen sus datos .

* Nota: en la práctica, los controladores eliminan la mayor parte de la lógica, desde ViewModel, que requiere pruebas unitarias. La máquina virtual se convierte en un contenedor tonto que requiere poca o ninguna prueba. Esto es algo bueno, ya que la VM es solo un puente entre el diseñador y el codificador, por lo que debe ser simple.

Incluso en MVVM, los controladores generalmente 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 el código del código subyacente de XAML para hacer que la edición de XAML sea una tarea más independiente . Todavía creamos 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 cierta forma de datos . No tienen idea de dónde provienen los datos.
  • Los ViewModels contienen 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 framework Sculpture code-gen 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 por los modelos View.

He comenzado un blog sobre este tema que agregaré a medida que pueda . 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 máquinas virtuales, pero lo abordaré en artículos posteriores.

Una ventaja adicional de usar un modelo MVCVM es que solo los objetos del controlador deben 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 sean mucho menos intensivas en 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 usando 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 la capacidad de respuesta.

Nota: Esta publicación ha sido editada varias veces, y no se dirigió específicamente a la pregunta estrecha formulada, por lo que he actualizado la primera parte para que ahora también cubra eso. Gran parte de la discusión, en los comentarios a continuación, se relaciona solo con ASP.Net y no con la imagen más amplia. Esta publicación tenía la intención de cubrir el uso más amplio de MVVM en Silverlight, WPF y ASP.Net y tratar de disuadir a las personas de reemplazar los controladores con ViewModels.


8
@Tomasz Zielinski: Cierto, pero "dónde se usan" no era la pregunta (o el punto de mi respuesta). Mi punto es que los controladores siguen siendo útiles en MVVM.
Gone Coding

58
Estoy de acuerdo. Mi comentario fue causado por la iluminación repentina y no porque no estuviese de acuerdo contigo.
Tomasz Zieliński

También utilizamos controladores para controlar el "flujo" de vistas en una interfaz de usuario similar a un asistente.
riezebosch

3
@Justin: Veo que mi redacción de esa oración es un poco ambigua. De hecho, me refiero a que las pruebas unitarias para todos los componentes son más fáciles de soportar, no específicamente solo para mejorar las pruebas de ViewModels (que, como usted señala, en realidad no hacen tanto en MVCVM ... que es lo que quiere). El beneficio real de los controladores es que en realidad está eliminando la mayoría de los requisitos para las pruebas del ViewModel (donde la gente sigue empujando la lógica del controlador) y colocándola donde pueda probarse (principalmente Controladores y Modelos). El comentario de reutilización es específico de las máquinas virtuales en esa oración. Lo he editado
Se fue la codificación el

77
@TomaszZielinski M (MVVM) C
Mohamed Emad

274

Creo que la forma más fácil de entender lo que se supone que significan estos acrónimos es olvidarse de ellos por un momento. En cambio, piense en el software con el que se originaron, cada uno de ellos. Realmente se reduce a la diferencia entre la primera web 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 la base de datos, las páginas HTML y el 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 plantilla. Para »código entre«, supongamos que el usuario de mapeo de códigos hace clic en acciones que posiblemente afecten a la base de datos, lo que definitivamente hace que se muestre otra vista. Eso es todo, al menos para el propósito de esta comparación.

Conservemos 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 programadores reales hicieron bien en evitar: la página HTML es esencialmente tonta y pasiva . El navegador es un cliente ligero, o si lo desea, un cliente pobre. No hay inteligencia en el navegador. Regla de recarga de página completa. La »vista« se genera de nuevo cada vez.

Recordemos que este modo web, a pesar de estar de moda, era terriblemente atrasado en comparación con el 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 manejan en la memoria. No hay basura como una recarga de página completa.

Y esta rica forma de escritorio es probablemente donde se originó el segundo acrónimo, MVVM. No se deje engañar por las letras, por la omisión de C. Los controladores todavía están allí. Necesitan serlo. Nada se quita. 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 = mala interactividad
  • MVVM = modelo, controlador, caché, vista = comunicación bidireccional = interactividad rica

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. Mira su programabilidad. Mira su consumo de memoria. Mire toda la interactividad de Javascript en las páginas web modernas.

Personalmente, creo que esta teoría y acrónimo de negocios es más fácil de entender al observar a qué se refiere en realidad concreta. Los conceptos abstractos son útiles, especialmente cuando se demuestran en materia concreta, por lo que la comprensión puede completar el círculo.

 


47
MVC no se originó en la web. Trygve Reenskaug introdujo MVC en Smalltalk-76 en la década de 1970.
Arialdo Martini

11
Incluso si se cambiara a "MVC se popularizó a través del diseño de aplicaciones web". Yo diría que esto es especulación sin una cita adecuada.
Dan Bechard

44
Arialdo: Gracias, no sabía sobre Smalltalk-76. (Jugó con otros juguetes en ese entonces. :) Bromas aparte, es interesante la antigüedad de algunos de estos conceptos. - @Dan, lo que escribí es: "[MVC] puede haber estado allí antes [de la web], pero la web es cómo se popularizó entre las masas de desarrolladores web". Sigo pensando que eso es correcto. No tengo una cita para ello, pero no creo que necesite una porque esa popularización masiva de MVC es parte de mi experiencia personal cuando comencé como desarrollador web a principios de la última década. Apache Struts estaba de moda en aquel entonces, con muchos beans para MVC.
Lumi

55
MVC no es "comunicación esencialmente unidireccional" ya que los navegadores emiten Gets y Posts todo el tiempo. Tanto Gets como Posts pueden cambiar los valores de campo encontrados en la cadena de consulta. Esto brinda a los navegadores una gran oportunidad para enviar información al controlador. MVC se creó sobre HTTP 1.0, que siempre tuvo en mente la comunicación bidireccional.
John Peters

13
Gracias Lumi Esto tenía mucho más sentido para mí que las otras respuestas. ¿Es correcto? No tengo idea. Pero desde mi perspectiva fue al menos coherente.
gcdev

175

MVVM Model-View ViewModel es similar a MVC, Model-View Controller

El controlador se reemplaza con un ViewModel . ViewModel se encuentra debajo de la capa de la interfaz de usuario. ViewModel expone los datos y los objetos de comando que necesita la vista. Podría pensar en esto como un objeto contenedor desde el que la vista va a obtener sus datos y acciones. ViewModel extrae sus datos del modelo.

Russel East hace un blog discutiendo más en detalle ¿Por qué MVVM es diferente de MVC?


81
La frase "El controlador se reemplaza con un Modelo de vista" no es correcta. En MVVM, ¿cuál es el papel del controlador es el enlace de datos (o enlace por convención si lo usa)?
DaniCE

99
MVVM solo tendrá sentido cuando utilice el enlace de datos bidireccional de WPF. De lo contrario, MVC / MVP, etc. sería suficiente.
Jeff

266
@DaniCE: Josh Smith:If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. …
todo

77
@OmShankar El 11 no es de ti mismo. Hay 10 personas en total y 12 opiniones en total. El dicho dice que las definiciones de estos patrones están tan abiertas a la interpretación que al menos dos personas se confundirán lo suficiente como para tener más de una opinión.
Dan Bechard

77
@DaniCE Bueno, este es en realidad el objetivo del enlace de datos de WPF, y Microsoft inventó MVVM, ya que uno puede omitir el controlador por completo, (alegando que la frase "El controlador se está reemplazando con un Modelo de vista" es incorrecta solo porque hay un controlador detrás de escena, es básicamente como afirmar que una afirmación "El lenguaje de nivel superior reemplaza el uso de código de máquina críptico por otros más legibles" es incorrecto porque el lenguaje de máquina detrás de escena todavía se está usando ...)
yoel halb

91

Por un lado, MVVM es una progresión del patrón MVC que usa XAML para manejar la pantalla. Este artículo describe algunas de las facetas de los dos.

El objetivo principal de la arquitectura Modelo / Vista / Modelo de vista parece ser que encima de los datos ("el Modelo"), hay otra capa de componentes no visuales ("el Modelo de vista") que mapean los conceptos de los datos más de cerca a los conceptos de la vista de los datos ("la Vista"). Es el ViewModel al que se une la Vista, no el Modelo directamente.


20
Creo que el párrafo que citó lo resume muy bien en mi humilde opinión. Un aspecto del ViewModel es que es una versión aplanada / alterada del modelo para la vista. Muchos otros patrones MV * se unen contra el modelo real .
Daniel Auger

1
?? "Muchos otros MV * patrones se unen de nuevo al modelo real” Realmente pensé que la vista siempre se supone que se unen al controlador de MVC, no importa qué.
PlagueHammer

99
Nocturne: en MVC clásico, View no tiene mucho que ver con el controlador, se vincula principalmente con Model. Piense en ello como un robot: el modelo representa la posición de las articulaciones del robot, View es un monitor LCD en el que ve el robot, el controlador es, por ejemplo, el teclado. En dicha configuración, Ver depende del Modelo, es decir, la posición espacial del robot, que puede ver en el monitor es una representación directa del Modelo.
Tomasz Zieliński

@Nocturne Lo que Daniel parecía decir es que, aunque oficialmente todos los MV * deberían usar una VM separada, muchos desarrolladores simplemente la ignoran y pasan el modelo real, y de hecho nada en las especificaciones, por ejemplo de MVC, no lo permite, sin embargo, en MVVM uno debe ser una VM responsable de la transición entre el modelo y la vista
yoel halb

Lo diría así: el modelo es lo más parecido al esquema DB. Cuando se ejecuta una consulta, puede proyectar los datos en tipos fuertes en la capa del modelo. El modelo de vista es una colección de cosas, incluidos objetos de modelo, pero puede y mantiene el estado de vista con respecto a los datos. El controlador es simplemente un policía de tráfico entre el modelo de vista y la vista y, por supuesto, la vista solo se refiere a los estados de vista.
John Peters

52

Microsoft proporcionó una explicación del patrón MVVM en el entorno de Windows aquí .

Aquí hay una sección crucial:

En el patrón de diseño Model-View-ViewModel, una aplicación se compone de tres componentes generales. ingrese la descripción de la imagen aquí

  • Modelo : representa el modelo de datos que consume su aplicación. Por ejemplo, en una aplicación para compartir imágenes, esta capa puede representar el conjunto de imágenes disponibles en un dispositivo y la API utilizada para leer y escribir en la biblioteca de imágenes.

  • Ver : una aplicación generalmente se compone de varias páginas de interfaz de usuario. Cada página que se muestra al usuario es una vista en terminología MVVM. La vista es el código XAML utilizado para definir y diseñar lo que ve el usuario. Los datos del modelo se muestran al usuario, y el trabajo de ViewModel es proporcionar a la IU estos datos en función del estado actual de la aplicación. Por ejemplo, en una aplicación para compartir imágenes, las vistas serían la interfaz de usuario que muestra al usuario la lista de álbumes en el dispositivo, las imágenes en un álbum y quizás otra que muestre al usuario una imagen en particular.

  • ViewModel : ViewModel vincula el modelo de datos, o simplemente el modelo, a la interfaz de usuario o vistas de la aplicación. Contiene la lógica con la que administrar los datos del modelo y expone los datos como un conjunto de propiedades a las que se puede unir la interfaz de usuario XAML o las vistas. Por ejemplo, en una aplicación para compartir imágenes, ViewModel expondrá una lista de álbumes y para cada álbum expondrá una lista de imágenes. La interfaz de usuario es independiente de dónde provienen las imágenes y cómo se recuperan. Simplemente conoce un conjunto de imágenes expuestas por ViewModel y se las muestra al usuario.


77
Tenga en cuenta que, si bien el artículo al que se hace referencia se aplica al desarrollo con Microsoft Stack, específicamente Windows Phone, y XAML, no tiene que ser así.
Richard Nalezynski el

Esta respuesta resalta el problema con el nombre "MVVM" - debe ser "VVMM" o "MVMV" - ¡MV-VM tiene las relaciones completamente al revés!
Etherman

45

Pensé que una de las principales diferencias era que en MVC, tu V lee tu M directamente y pasa por la C para manipular los datos, mientras que en MVVM, tu VM actúa como un proxy M, además de proporcionarte la funcionalidad disponible. V.

Si no estoy lleno de basura, me sorprende que nadie haya creado un híbrido, donde su VM es simplemente un proxy M y C proporciona toda la funcionalidad.


1
+1. El término es el correcto, creo. pero acerca de crear híbrido M-MProxy-VC, ¿no es eso mucha separación? Creo que sería suficiente con MVC, mientras que M es un modelo con soporte completo de Binding. ;)
ktutnik

2
+1. Como comenté anteriormente, creo que MVC se usa para diseñar toda la aplicación (web), mientras que MVVM se usa dentro del componente View de MVC.
Tomasz Zieliński

23
@ktutnik: el modelo generalmente se encuentra en el servidor, mientras que ViewModel vive en el cliente. Por lo tanto, no es factible que HTML se una directamente al modelo del lado del servidor. Por lo tanto, necesitamos ModelView, que actúa como un conjunto de datos de trabajo local no guardado extraído del modelo utilizando, por ejemplo, AJAX / JSON.
Tomasz Zieliński

1
De hecho, la vista "lee" los datos del modelo porque el controlador ya los ha puesto allí. Me gusta referirme a él como una "inyección de datos" por parte del controlador, ya que es realmente el controlador el que está a cargo. Toda la vista hace en render y dispara eventos en mi mente.
John Peters

3
Pido disculpas pero no estoy de acuerdo con la interpretación MVVM. Un modelo de vista no tiene idea de una vista o de cómo se verá o cómo responderá, y un modelo tampoco tiene idea de un modelo de vista. De hecho, una vista ni siquiera debería saber de un modelo, solo un modelo de vista. El modelo debe representar los datos y el estado de la aplicación, ViewModel debe traducir el estado a datos con capacidad de interfaz de usuario (recomiendo todas las primitivas en este punto) y una Vista debe reaccionar a la traducción de ViewModels. Los datos a menudo serán los mismos, pero aún se deben empaquetar y volver a entregar a través de un ViewModel y no existen controladores.
Michael Puckett II

24

MVC es un entorno controlado y MVVM es un entorno reactivo.

En un entorno controlado, debería tener menos código y una fuente común de lógica; que siempre debe vivir dentro del controlador. Sin embargo; En el mundo web, MVC se divide fácilmente en lógica de creación de vista y lógica dinámica de vista. La creación vive en el servidor y la vida dinámica en el cliente. Esto se ve mucho con ASP.NET MVC combinado con AngularJS, mientras que el servidor creará una Vista y pasará un Modelo y lo enviará al cliente. El cliente luego interactuará con la Vista, en cuyo caso AngularJS interviene como un controlador local. Una vez enviado, el Modelo o un nuevo Modelo se devuelve al controlador del servidor y se maneja. (Por lo tanto, el ciclo continúa y hay muchas otras traducciones de este manejo cuando se trabaja con sockets o AJAX, etc., pero sobre todo la arquitectura es idéntica).

MVVM es un entorno reactivo, lo que significa que normalmente escribe código (como desencadenantes) que se activará en función de algún evento. En XAML, donde MVVM prospera, todo esto se hace fácilmente con el marco de enlace de datos incorporado, PERO como se mencionó, esto funcionará en cualquier sistema en cualquier Vista con cualquier lenguaje de programación. No es específico de la EM. El ViewModel se dispara (generalmente un evento de cambio de propiedad) y la Vista reacciona en función de los desencadenantes que cree. Esto puede ser técnico, pero la conclusión es que la vista no tiene estado y no tiene lógica. Simplemente cambia de estado en función de los valores. Además, los ViewModels no tienen estado con muy poca lógica, y los Modelos son el Estado con lógica esencialmente Cero, ya que solo deberían mantener el estado. Describo esto como el estado de la aplicación (Modelo), el traductor de estado (ViewModel) y luego el estado visual / interacción (Ver).

En una aplicación MVC de escritorio o del lado del cliente, debe tener un Modelo, y el Modelo debe ser utilizado por el Controlador. Según el modelo, el controlador modificará la vista. Las vistas generalmente están vinculadas a controladores con interfaces para que el controlador pueda trabajar con una variedad de vistas. En ASP.NET, la lógica de MVC está ligeramente hacia atrás en el servidor, ya que el Controlador administra los Modelos y los pasa a una Vista seleccionada. Luego, la Vista se llena con datos basados ​​en el modelo y tiene su propia lógica (generalmente otro conjunto MVC como el hecho con AngularJS). La gente discutirá y confundirá esto con la aplicación MVC e intentará hacer ambas cosas, en cuyo punto el mantenimiento del proyecto eventualmente se convertirá en un desastre. SIEMPRE coloque la lógica y el control en una ubicación cuando use MVC. NO escriba la lógica de Vista en el código detrás de la Vista (o en la Vista a través de JS para web) para acomodar los datos del Controlador o Modelo. Deje que el controlador cambie la vista. La ÚNICA lógica que debería vivir en una Vista es lo que sea necesario para crear y ejecutar a través de la Interfaz que está utilizando. Un ejemplo de esto es enviar un nombre de usuario y contraseña. Ya sea en el escritorio o en la página web (en el cliente), el Controlador debe manejar el proceso de envío cada vez que la Vista active la acción Enviar. Si se hace correctamente, siempre puede orientarse fácilmente en una aplicación MVC web o local. Ya sea en el escritorio o en la página web (en el cliente), el Controlador debe manejar el proceso de envío cada vez que la Vista active la acción Enviar. Si se hace correctamente, siempre puede orientarse fácilmente en una aplicación MVC web o local. Ya sea en el escritorio o en la página web (en el cliente), el Controlador debe manejar el proceso de envío cada vez que la Vista active la acción Enviar. Si se hace correctamente, siempre puede orientarse fácilmente en una aplicación MVC web o local.

MVVM es personalmente mi favorito, ya que es completamente reactivo. Si un modelo cambia de estado, el modelo de vista escucha y traduce ese estado, ¡y listo! La Vista está escuchando el ViewModel para el cambio de estado y también se actualiza en función de la traducción del ViewModel. Algunas personas lo llaman MVVM puro, pero en realidad solo hay uno y no me importa cómo lo discutas, y siempre es MVVM puro donde la vista no contiene absolutamente ninguna lógica.

Aquí hay un pequeño ejemplo: supongamos que desea que se deslice un menú al presionar un botón. En MVC tendrá una acción MenuPressed en su interfaz. El Controlador sabrá cuándo hace clic en el botón Menú y luego le dice a la Vista que se deslice en el Menú basado en otro método de Interfaz como SlideMenuIn. ¿Un viaje de ida y vuelta por qué motivo? En caso de que el Controlador decida que no puede o quiere hacer otra cosa, es por eso. El Controlador debe estar a cargo de la Vista sin que la Vista haga nada a menos que el Controlador lo indique. SIN EMBARGO; en MVVM, el menú de diapositivas en la animación debe estar integrado y ser genérico y, en lugar de que se le pida que lo deslice, lo hará en función de algún valor. Entonces escucha el ViewModel y cuando el ViewModel dice, IsMenuActive = true (o sin embargo) la animación para eso tiene lugar. Ahora, Dicho esto, quiero hacer otro punto REALMENTE CLARO y POR FAVOR preste atención. IsMenuActive es probablemente un diseño MALO MVVM o ViewModel. Al diseñar un modelo de vista, nunca debe asumir que una vista tendrá alguna característica y solo pasará el estado del modelo traducido. De esa manera, si decide cambiar su Vista para eliminar el Menú y simplemente mostrar los datos / opciones de otra manera, a ViewModel no le importa. Entonces, ¿cómo gestionarías el menú? Cuando los datos tienen sentido, así es como. Entonces, una forma de hacer esto es darle al Menú una lista de opciones (probablemente una matriz de ViewModels internos). Si esa lista tiene datos, el Menú sabe abrirse a través del disparador, si no, entonces sabe esconderse a través del disparador. Simplemente tiene datos para el menú o no en ViewModel. NO decida mostrar / ocultar esos datos en ViewModel. simplemente traduzca el estado del Modelo. De esta manera, la Vista es completamente reactiva y genérica y se puede utilizar en muchas situaciones diferentes.

Probablemente, todo esto no tenga ningún sentido si aún no está al menos un poco familiarizado con la arquitectura de cada uno y aprenderlo puede ser muy confuso, ya que encontrará MUCHA información MALA en la red.

Entonces ... cosas a tener en cuenta para hacer esto bien. Decide por adelantado cómo diseñar tu aplicación y STICK TO IT.

Si haces MVC, lo cual es genial, entonces asegúrate de que tu Controlador sea manejable y tenga el control total de tu Vista. Si tiene una vista grande, considere agregar controles a la vista que tengan diferentes controladores. SOLO NO conecte esos controladores a diferentes controladores. Muy frustrante de mantener. Tómese un momento y diseñe las cosas por separado de una manera que funcione como componentes separados ... Y siempre deje que el Controlador le diga al Modelo que confirme o conserve el almacenamiento. La configuración de dependencia ideal para MVC en es Ver ← Controlador → Modelo o con ASP.NET (no empiece) Modelo ← Ver ↔ Controlador → Modelo (donde el Modelo puede ser el mismo o un Modelo totalmente diferente de Controlador a Vista)... por supuesto, la única necesidad de conocer el Controlador en Vista en este punto es principalmente para referencia de punto final para saber dónde volver a pasar un Modelo.

Si haces MVVM, bendigo tu amable alma, ¡pero tómate el tiempo para hacerlo CORRECTAMENTE! No use interfaces para uno. Deje que su vista decida cómo se verá según los valores. Juega con la vista con datos simulados. Si termina teniendo una Vista que le muestra un Menú (como en el ejemplo) aunque no lo quería en ese momento, entonces BUENO. Su vista funciona como debería y reacciona en función de los valores como debería. Simplemente agregue algunos requisitos más a su disparador para asegurarse de que esto no suceda cuando ViewModel esté en un estado traducido particular o ordene a ViewModel que vacíe este estado. En su ViewModel NO elimine esto con lógica interna, ya sea como si estuviera decidiendo desde allí si la Vista debería verlo o no. Recuerde que no puede asumir que hay un menú o no en ViewModel. Y finalmente, el Modelo solo debería permitirle cambiar y muy probablemente almacenar el estado. Aquí es donde la validación y todo ocurrirá; por ejemplo, si el Modelo no puede modificar el estado, simplemente se marcará como sucio o algo así. Cuando ViewModel se dé cuenta de esto, traducirá lo que está sucio, y entonces View se dará cuenta de esto y mostrará información a través de otro disparador. Todos los datos en la Vista pueden vincularse al ViewModel para que todo pueda ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias, deben apuntar así y solo así Si modifica el estado, simplemente se marcará como sucio o algo así. Cuando ViewModel se dé cuenta de esto, traducirá lo que está sucio, y entonces View se dará cuenta de esto y mostrará información a través de otro disparador. Todos los datos en la Vista pueden vincularse al ViewModel para que todo pueda ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias, deben apuntar así y solo así Si modifica el estado, simplemente se marcará como sucio o algo así. Cuando ViewModel se dé cuenta de esto, traducirá lo que está sucio, y entonces View se dará cuenta de esto y mostrará información a través de otro disparador. Todos los datos en la Vista pueden vincularse al ViewModel para que todo pueda ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias, deben apuntar así y solo así Todos los datos en la Vista pueden vincularse al ViewModel para que todo pueda ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias, deben apuntar así y solo así Todos los datos en la Vista pueden vincularse al ViewModel para que todo pueda ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias, deben apuntar así y solo asíVer → Modelo de vista → Modelo (y una nota al margen aquí ... y esto probablemente se discutirá también, pero no me importa ... NO PASE EL MODELO a la VISTA a menos que ese MODELO sea inmutable; de ​​lo contrario, envuélvalo con un ViewModel apropiado. La vista no debería ver un período de modelo. Le doy a las ratas un crack de la demostración que has visto o cómo lo has hecho, eso está mal).

Aquí está mi consejo final ... Mire una aplicación MVC bien diseñada, pero muy simple, y haga lo mismo para una aplicación MVVM. Uno tendrá más control con flexibilidad limitada a cero, mientras que el otro no tendrá control y flexibilidad ilimitada.

Un entorno controlado es bueno para administrar toda la aplicación desde un conjunto de controladores o (una sola fuente), mientras que un entorno reactivo se puede dividir en repositorios separados sin ninguna idea de lo que está haciendo el resto de la aplicación. Microgestión vs gestión libre.

Si no te he confundido lo suficiente, intenta contactarme ... No me importa revisar esto con todo detalle con ilustraciones y ejemplos.

Al final del día, todos somos programadores y con esa anarquía vive dentro de nosotros cuando codificamos ... Así que las reglas se romperán, las teorías cambiarán, y todo esto terminará siendo un lavado de cerdos ... Pero cuando se trabaja en grande proyectos y en equipos grandes, realmente ayuda a acordar un patrón de diseño y aplicarlo. Algún día hará que los pequeños pasos adicionales que se tomen al principio se conviertan en grandes saltos de ahorro más adelante.


Increíblemente detallada y precisa respuesta! Lo hizo claro como el cristal para mí. :-)
ankush981

"aprenderlo puede ser muy confuso ya que encontrarás MUCHA información MALA en la red". Sí. Como alguien que parece tener mucha experiencia con estos patrones de diseño, ¿conoce algún buen tutorial / guía?
MarredCheese

1
Para ser honesto, mi conocimiento MVVM ha pasado por años o prueba y error, y lo he usado / hecho de varias maneras en función de los esfuerzos del equipo. Recientemente (hace 2 años) pude poner mi propia experiencia en un plan de juego resumido y liderar un equipo de principio a fin, y tuvimos un gran éxito. Dicho esto, no puedo señalarlo en ningún lugar y disculparme. Puedo decir que tienes razón, debido a las diversas opiniones es muy confuso, pero, en mi opinión, con MVVM es lo más genérico posible. Haga que ViewModels sea capaz de permitir que las vistas se unan y trabajen con datos estrictamente, pero para CUALQUIER vista ...
Michael Puckett II

1
En otras palabras, NUNCA haga que el modelo de vista asuma que una vista se verá o actuará de alguna manera. ViewModel, para mí, se usa mejor como una API, pero con una comunicación estricta. Siga el plan del juego para vincular, editar, ordenar, etc. Si la Vista necesita una lógica adicional para funcionar de una manera específica, eso no tiene nada que ver con la aplicación o los datos (como una animación o un cuadro desplegable ...), entonces esa lógica pertenece en el nivel de Vista en algún lugar de alguna manera. Una vez más, hay una gran cantidad de opiniones y esto es solo mío, pero tengo una sólida formación aquí y un historial sólido hasta ahora.
Michael Puckett II

Tengo aplicaciones de ejemplo que no me importa compartir y que no me importaría configurar un programa simple y contarle a usted o a cualquier otra persona si lo desea o tiene curiosidad.
Michael Puckett II

23

Diferencia simple: (Inspirado en el curso Coursera AngularJS de Yaakov)

ingrese la descripción de la imagen aquí

MVC (controlador de vista de modelo)

  1. Modelos: los modelos contienen información de datos. No llama ni usa Controlador y Vista. Contiene la lógica de negocios y formas de representar datos. Algunos de estos datos, de alguna forma, pueden mostrarse en la vista. También puede contener lógica para recuperar los datos de alguna fuente.
  2. Controlador: actúa como la conexión entre la vista y el modelo. Ver llamadas Controlador y Controlador llama al modelo. Básicamente informa al modelo y / o la vista para cambiar según corresponda.
  3. Ver: ofertas con la parte de la interfaz de usuario. Interactúa con el usuario.

MVVM (vista de modelo, modelo de vista)

ViewModel :

  1. Es la representación del estado de la vista.
  2. Contiene los datos que se muestran en la vista.
  3. Responde para ver eventos, también conocido como lógica de presentación.
  4. Llama a otras funcionalidades para el procesamiento de la lógica de negocios.
  5. Nunca le pide directamente a la vista que muestre nada.

18

MVVM es un refinamiento (discutible) del patrón del Modelo de Presentación . Digo discutible, porque la única diferencia está en cómo WPF proporciona la capacidad de hacer enlace de datos y manejo de comandos.


1
En 2009, esta respuesta probablemente fue buena, pero hoy en día, no hay debate, ya que incluso los controles HTML Helper de MSFT permiten la vinculación utilizando los infames ayudantes "For". Knockout tiene que ver con el enlace de datos en el lado del cliente.
John Peters

1
Dije esto, en 2009, porque demasiadas personas en la comunidad aceptaron esta respuesta. Dije que era discutible, porque MVVM y Presentation Model realmente son el mismo patrón con diferentes nombres. Gracias a la popularidad en WPF, a menudo se llama MVVM en otros marcos hoy en día, pero cualquiera de los nombres es exacto.
wekempf

15

El modelo de vista es un modelo "abstracto" para los elementos de su interfaz de usuario. Debe permitirle ejecutar los comandos y las acciones en su vista de una manera no visual (por ejemplo, para probarlo).

Si ha trabajado con MVC, es probable que alguna vez le haya resultado útil crear objetos modelo para reflejar el estado de su vista, por ejemplo, para mostrar y ocultar algún cuadro de diálogo de edición, etc.

El patrón MVVM es simplemente la generalización de esa práctica a todos los elementos de la interfaz de usuario.

Y no es un patrón de Microsoft, lo que se agrega es que los enlaces de datos WPF / Silverlight son especialmente adecuados para trabajar con este patrón. Pero nada lo detiene para usarlo con caras de servidor java, por ejemplo.


13

Las otras respuestas pueden no ser fáciles de entender para alguien que no está muy familiarizado con el tema de los patrones arquitectónicos. Alguien que es nuevo en la arquitectura de aplicaciones podría querer saber cómo su elección puede afectar su aplicación en la práctica y de qué se trata todo este alboroto en las comunidades.

Intentando arrojar algo de luz sobre lo anterior, inventé este guión con MVVM, MVP y MVC. La historia comienza cuando un usuario hace clic en el botón 'ENCONTRAR' en una aplicación de búsqueda de películas ...:

Usuario: haga clic en ...

Ver : ¿Quién es ese? [ MVVM | MVP | MVC ]

Usuario: Acabo de hacer clic en el botón de búsqueda ...

Ver : Ok, espera un segundo ... [ MVVM | MVP | MVC ]

( Ver llamando al ViewModel | Presentador | Controlador ...) [ MVVM | MVP | MVC ]

Ver : Hola ViewModel | Presentador | Controlador , un usuario acaba de hacer clic en el botón de búsqueda, ¿qué debo hacer? [ MVVM | MVP | MVC ]

ViewModel | Presentador | Controlador : Hey Vista , ¿hay algún término de búsqueda en esa página? [ MVVM | MVP | MVC ]

Ver : Sí, ... aquí está ... "piano" [ MVVM | MVP | MVC ]

—— Esta es la diferencia más importante entre MVVM Y MVP | MVC ———

Presentador : Gracias Ver , ... mientras busco el término de búsqueda en el Modelo , muéstrele una barra de progreso [ MVP | MVC ]

( Presentador | El controlador está llamando al Modelo ...) [ MVP | MVC ]

ViewController : Gracias, buscaré el término de búsqueda en el Modelo pero no lo actualizaré directamente. En su lugar, activaré eventos para searchResultsListObservable si hay algún resultado. Así que será mejor que observes eso. [ MVVM ]

(Mientras observa en cualquier desencadenante en searchResultsListObservable, la Vista cree que debería mostrar alguna barra de progreso al usuario, ya que ViewModel no le hablaría sobre eso)

——————————————————————————————

ViewModel | Presentador | Controlador : Hola Modelo , ¿Tiene alguna coincidencia para este término de búsqueda ?: “piano” [ MVVM | MVP | MVC ]

Modelo : Hola ViewModel | Presentador | Controlador , déjame comprobar ... [ MVVM | MVP | MVC ]

(El modelo está haciendo una consulta a la base de datos de películas ...) [ MVVM | MVP | MVC ]

( Después de un tiempo … )

———— Este es el punto divergente entre MVVM , MVP y MVC ————–

Modelo : Encontré una lista para ti, ViewModel | Presentador , aquí está en JSON "[{" nombre ":" Profesor de piano "," año ": 2001}, {" nombre ":" Piano "," año ": 1993}]" [ MVVM | MVP ]

Modelo : hay algunos resultados disponibles, controlador. Creé una variable de campo en mi instancia y la rellené con el resultado. Su nombre es "searchResultsList" [ MVC ]

( Presentador | Controlador agradece al Modelo y vuelve a la Vista ) [ MVP | MVC ]

Presentador : Gracias por esperar Vista , encontré una lista de resultados coincidentes para usted y los arreglé en un formato presentable: ["Profesor de piano 2001", "Piano 1993"]. También oculta la barra de progreso ahora [ MVP ]

Controlador : Gracias por esperar Vista , le he preguntado a Model sobre su consulta de búsqueda. Dice que ha encontrado una lista de resultados coincidentes y los ha almacenado en una variable llamada "searchResultsList" dentro de su instancia. Puedes conseguirlo desde allí. También oculta la barra de progreso ahora [ MVC ]

ViewModel : se notificará a cualquier observador en searchResultsListObservable que hay esta nueva lista en formato presentable: ["Piano Teacher 2001 ″," Piano 1993 "]. [ MVVM ]

Ver : Muchas gracias Presentador [ MVP ]

Vista : Gracias " Controlador " [ MVC ] (Ahora la Vista se cuestiona a sí misma: ¿Cómo debo presentar los resultados que obtengo del Modelo al usuario? ¿Debería el año de producción de la película ser el primero o el último ...?)

Ver : Oh, hay un nuevo desencadenante en searchResultsListObservable ..., bueno, hay una lista presentable, ahora solo tengo que mostrarla en una lista. También debería ocultar la barra de progreso ahora que tengo el resultado. [ MVVM ]

En caso de que esté interesado, he escrito una serie de artículos aquí , comparando MVVM, MVP y MVC mediante la implementación de una aplicación de Android de búsqueda de películas.


Hay una gran respuesta debajo de todo el texto de sabor aquí ... Con un poco de formato y una pequeña conversación entre los componentes, este podría ser el mejor en esta página.
neonblitzer

10

Inyección de modelos de vista fuertemente tipados en la vista usando MVC

  1. El controlador es responsable de actualizar el ViewModel e inyectarlo en la Vista. (para obtener solicitudes)
  2. ViewModel es el contenedor de DataContext y el estado de vista, como el último elemento seleccionado, etc.
  3. El modelo contiene entidades DB y está muy cerca del esquema DB que realiza las consultas y el filtrado. (Me gusta EF y LINQ para esto)
  4. El modelo también debe considerar repositorios y / o proyección de resultados en tipos fuertes (EF tiene un gran método ... EF.Database.Select (querystring, parms) para acceso directo de ADO para inyectar consultas y recuperar tipos fuertes. Esto aborda el EF es un argumento lento ¡ EF NO ES LENTO !
  5. ViewModel obtiene los datos y realiza las reglas comerciales y la validación
  6. El controlador en la publicación posterior llamará el método ViewModel Post y esperará los resultados.
  7. El controlador inyectará el Viewmodel recién actualizado a la Vista. El View utiliza sólo es fuerte tipo de enlace .
  8. La vista simplemente representa los datos y publica los eventos nuevamente en el controlador. (ver ejemplos a continuación)
  9. MVC intercepta la solicitud entrante y la dirige al controlador adecuado con un tipo de datos seguro

En este modelo no hay más contacto de nivel HTTP con los objetos de solicitud o respuesta, ya que la máquina MVC de MSFT nos lo oculta.

En la aclaración del punto 6 anterior (por solicitud) ...

Suponga un ViewModel como este:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

El método del controlador de la publicación se verá así (ver más abajo), tenga en cuenta que la instancia de mvm es instanciada automáticamente por los mecanismos de enlace MVC. Como resultado, nunca tendrá que desplegarse en la capa de cadena de consulta. ¡Esto es MVC instanciando el ViewModel para usted basado en las cadenas de consulta!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Tenga en cuenta que para que este método de acción anterior funcione como lo desea, debe tener un CTOR nulo definido que inicialice las cosas que no se devuelven en la publicación. La publicación posterior también debe publicar pares de nombre / valor para aquellas cosas que cambiaron. Si faltan pares de nombre / valor, el motor de enlace MVC hace lo correcto, ¡que simplemente no es nada! Si esto sucede, es posible que te encuentres diciendo "Estoy perdiendo datos en las publicaciones" ...

La ventaja de este patrón es que ViewModel hace todo el trabajo de "desorden" en la interfaz con la lógica Modelo / Negocio, el controlador es simplemente un tipo de enrutador. Es SOC en acción.


¿Puedes aclarar el ítem 6? Me doy cuenta de que solo está cubriendo ASP.Net, pero parece estar agregando una dependencia no deseada al ViewModel. (por ejemplo, conocimiento de dónde provienen / van los datos). Un ejemplo de código (¿pseudocódigo?) Sería bueno para aclarar esta respuesta y mostrar qué partes son del lado del servidor y cuáles del lado del cliente.
Gone Coding

9

MVVM agrega el modelo de vista a la mezcla. Esto es importante, ya que le permite utilizar gran parte del enfoque vinculante de WPF, sin incluir todas las piezas específicas de la interfaz de usuario en su modelo habitual.

Puedo estar equivocado, pero no estoy seguro de que MVVM realmente fuerce al controlador a la mezcla. Creo que el concepto está más en línea con: http://martinfowler.com/eaaDev/PresentationModel.html . Creo que las personas eligen combinarlo con MVC, no es que esté integrado en el patrón.


3
MVVM, estrictamente hablando, es el Modelo de Presentación, aunque MVVM se está convirtiendo en el nombre preferido para la realización específica del patrón por WPF.
wekempf

Convenido. El modelo de vista en MVC "ES" la máquina de estado para la vista. Contiene el contexto de datos y rastrea toda la información del elemento seleccionado, así como también puede contener toda la lógica de validación utilizando la interfaz IValidatableObject. ViewModel interactúa con la base de datos en la capa del modelo que puede usar modelos con tipos fuertes. MVVM en WPF ES el controlador de MVC. Pero el controlador de MVC es mucho más limpio, es esencial un controlador de enrutamiento.
John Peters

9

Por lo que puedo decir, el MVVM se asigna al MV de MVC, lo que significa que en un patrón MVC tradicional, la V no se comunica directamente con la M. En la segunda versión de MVC, hay un enlace directo entre M y V. MVVM parece tomar todas las tareas relacionadas con la comunicación M y V, y acoplarlo para desacoplarlo de la C. En efecto, todavía existe un flujo de trabajo de aplicación de mayor alcance (o implementación de los escenarios de uso) que no se tienen totalmente en cuenta en MVVM. Este es el papel del controlador. Al eliminar estos aspectos de nivel inferior de los controladores, son más limpios y hacen que sea más fácil modificar el escenario de uso de la aplicación y la lógica empresarial, lo que también hace que los controladores sean más reutilizables.


1
En mi humilde opinión, diría que "hacer que los controladores sean más reutilizables" es una declaración demasiado amplia y contraproducente para los "controladores" generales de ASP.Net (es decir, no la capa de lógica de negocios), ya que esos controladores generalmente contienen las partes de la aplicación que son aplicaciones. específica . Las vistas, los modelos, los modelos de vista y la lógica empresarial son los que deben ser reutilizables. Pensé que tratar los módulos de lógica de negocios como proveedores de servicios, no como controladores, sería una mejor opción.
Gone Coding

Pero estás hablando del "ViewModel" en Asp.net, no del patrón de diseño MVVM. Dos cosas diferentes
Luis

9

Me sorprende que esta sea una respuesta muy votada sin mencionar el origen de MVVM. MVVM es un término popular utilizado en la comunidad de Microsoft y se origina en el Modelo de presentación de Martin Fowler . Entonces, para comprender el motivo del patrón y las diferencias con los demás, lo primero que debe leer es el artículo original sobre el patrón.


Wow ... ¿Entonces tanto MVC como MVVM vinieron de SmallTalk? Aparentemente estaban muy adelantados a su tiempo ...
MattE

En realidad, decir que se originó en el Modelo de presentación de Martin Fowler no es exacto. Es muy difícil determinar qué vino primero, pero ambos patrones (permitiendo que sean realmente el mismo patrón) se obtuvieron de forma independiente y aproximadamente al mismo tiempo.
wekempf

6

Bueno, generalmente MVC se usa en el desarrollo web y MVVM es más popular en el desarrollo de WPF / Silverlight. Sin embargo, a veces la arquitectura web puede tener una mezcla de MVC y MVVM.

Por ejemplo: puede usar knockout.js y en este caso tendrá MVVM en su lado del cliente. Y el lado del servidor de su MVC también puede cambiar. En las aplicaciones complejas, nadie usa el modelo puro. Puede tener sentido usar un ViewModel como un "Modelo" de MVC y su Modelo real básicamente será parte de esta VM. Esto le brinda una capa de abstracción adicional.


Lo que el 'desarrollo web' llama 'MVC' no es más que la separación de preocupaciones y no el auténtico MVC que precedió a la web.
Terrence Brannon

4

MVVMC, o tal vez MVC +, parece ser un enfoque viable para el desarrollo de aplicaciones empresariales y rápidas. Si bien es bueno separar la interfaz de usuario de la lógica de negocios e interacción, el patrón MVVM 'puro' y la mayoría de los ejemplos disponibles funcionan mejor en vistas singulares.

No estoy seguro acerca de sus diseños, pero la mayoría de mis aplicaciones, sin embargo, contienen páginas y varias vistas (reutilizables) y, por lo tanto, los ViewModels necesitan interactuar en algún grado. Usar la página como controlador anularía el propósito del MVVM por completo, por lo que no usar un enfoque "VM-C" para la lógica subyacente podría resultar en ... bueno ... construcciones desafiantes a medida que la aplicación madure. Incluso en VB-6, la mayoría de nosotros probablemente dejamos de codificar la lógica empresarial en el evento Button y comenzamos a 'transmitir' comandos a un controlador, ¿verdad? Recientemente miré muchos marcos emergentes sobre ese tema; mi favorito claramente es el enfoque de Magallanes (en codeplex). ¡Feliz codificación!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References


4

El controlador no se reemplaza por un modelo de vista en MVVM, porque el modelo de vista tiene una funcionalidad totalmente diferente a un controlador. Todavía necesita un controlador, porque sin un controlador su modelo, ViewModel y View no harán mucho ... En MVVM también tiene un controlador, el nombre MVVM es simplemente engañoso.

MVVMC es el nombre correcto en mi humilde opinión.

Como puede ver, ViewModel es solo una adición al patrón MVC. Mueve la lógica de conversión (por ejemplo, convertir objetos en una cadena) desde el controlador al modelo de vista.


4

Hice un artículo medio para esto.

MVVM

  1. Ver ➡ ViewModel ➡ Modelo

    • La vista tiene una referencia al ViewModel pero no al revés.
    • ViewModel tiene una referencia al Modelo pero no al revés.
    • La Vista no tiene referencia al Modelo y viceversa.
  2. Si está utilizando un controlador, puede tener una referencia a Vistas y ViewModels , aunque un Controlador no siempre es necesario como se demuestra en SwiftUI .

  3. Enlace de datos : creamos escuchas para las propiedades de ViewModel.
class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

diferencias en la configuración

  1. La lógica empresarial se mantiene en el controlador para MVC y ViewModels para MVVM.
  2. Los eventos se pasan directamente de la Vista al controlador en MVC, mientras que los eventos se pasan de la Vista al Modelo de vista al Controlador (si hay uno) para MVVM.

Características comunes

  1. Tanto MVVM como MVC no permiten que la Vista envíe mensajes directamente a los Modelos.
  2. Ambos tienen modelos.
  3. Ambos tienen puntos de vista.

Ventajas de MVVM

  1. Debido a que los ViewModels tienen lógica empresarial, son objetos concretos más pequeños que los hacen fáciles de unir pruebas. Por otro lado, en MVC, la lógica de negocios está en ViewController. ¿Cómo puede confiar en que una prueba unitaria de un controlador de vista es completamente segura sin probar todos los métodos y oyentes simultáneamente? No puede confiar completamente en los resultados de la prueba unitaria.
  2. En MVVM, debido a que la lógica de negocios se desvía del controlador a unidades atómicas de ViewModel, el tamaño de ViewController se reduce y esto hace que el código de ViewController sea más legible.

Ventajas de MVC

  1. Proporcionar lógica empresarial dentro del controlador reduce la necesidad de ramificación y, por lo tanto, es más probable que las declaraciones se ejecuten en la memoria caché, lo que es más eficaz que la encapsulación de la lógica empresarial en ViewModels.
  2. Brindar lógica de negocios en un solo lugar puede acelerar el proceso de desarrollo para aplicaciones simples, donde no se requieren pruebas. No sé cuándo no se requieren pruebas.
  3. Proporcionar lógica empresarial en ViewController es más fácil de pensar para los nuevos desarrolladores.

1
La mejor explicación
p32094

2

Desde un punto de vista práctico, MVC (Modelo-Vista-Controlador) es un patrón. Sin embargo, MVC cuando se usa como ASP.net MVC, cuando se combina con Entity Framework (EF) y las "herramientas de poder" es un enfoque muy poderoso y parcialmente automatizado para llevar bases de datos, tablas y columnas a una página web, ya sea para Operaciones CRUD u operaciones R (Recuperar o Leer) solamente. Al menos cuando utilicé MVVM, los modelos de vista interactuaron con modelos que dependían de objetos comerciales, que a su vez fueron "hechos a mano" y después de mucho esfuerzo, uno tuvo la suerte de obtener modelos tan buenos como lo que EF le da a uno " -De la caja". Desde el punto de vista práctico de la programación, MVC parece una buena opción porque ofrece muchas utilidades listas para usar, pero aún existe la posibilidad de agregar campanas y silbatos.


2

Como complemento de muchas de las respuestas dadas, quería agregar una perspectiva adicional desde la web moderna del lado del cliente o desde el punto de vista de la aplicación web enriquecida .

De hecho, en la actualidad, los sitios web simples y las aplicaciones web más grandes se crean comúnmente con muchas bibliotecas populares como Bootstrap. Construido por Steve Sanderson, Knockout proporciona soporte para el patrón MVVM que imita uno de los comportamientos más importantes en el patrón: el enlace de datos a través del modelo de vista. Con un poco de JavaScript, se pueden implementar datos y lógica que luego se pueden agregar a los elementos de la página con data-bindatributos HTML simples , similar al uso de muchas de las características de Bootstrap . Juntas, estas dos bibliotecas solo ofrecen contenido interactivo; y cuando se combina con el enrutamiento, este enfoque puede resultar en un enfoque simple pero poderoso para construir la Aplicación de Página Única .

Del mismo modo, un marco moderno del lado del cliente como Angular sigue el patrón MVC por convención, pero también agrega un Servicio. Curiosamente, se promociona como Model-View-Whatever (MVW). (Consulte esta publicación sobre Desbordamiento de pila ).

Además, con el surgimiento de marcos web progresivos como Angular 2, estamos viendo un cambio en la terminología y quizás un nuevo patrón arquitectónico en el que los Componentes forman parte de una Vista o Plantilla e interactúan con un Servicio, todo lo cual puede estar contenido en un Módulo; y una serie de módulos conforma la aplicación.


2

Solía ​​pensar que MVC y MVVM son lo mismo. Ahora, debido a la existencia de Flux, puedo notar la diferencia:

En MVC, para cada vista en su aplicación, tiene un modelo y un controlador, por lo que lo llamaría ver, ver modelo, ver controlador. El patrón no le dice cómo una vista puede comunicarse con otra. Por lo tanto, en diferentes marcos hay diferentes implementaciones para eso. Por ejemplo, hay implementaciones donde los controladores se comunican entre sí, mientras que en otras implementaciones hay otro componente que media entre ellos. Incluso hay implementaciones en las que los modelos de vista se comunican entre sí, lo que es una ruptura del patrón MVC porque el controlador de vista solo debe acceder al modelo de vista.

En MVVM, también tiene un modelo de vista para cada componente. El patrón no especifica cómo debería influir la vista en el modelo de vista, por lo que la mayoría de los marcos solo incluyen la funcionalidad del controlador en el modelo de vista. Sin embargo, MVVM le dice que los datos de su modelo de vista deben provenir del modelo, que es el modelo completo que no es consciente o personalizado para una vista específica.

Para demostrar la diferencia, tomemos el patrón Flux. El patrón de flujo indica cómo se deben comunicar las diferentes vistas en la aplicación. Cada vista escucha una tienda y dispara acciones utilizando el despachador. El despachador, a su vez, informa a todas las tiendas sobre la acción que se acaba de realizar y las tiendas se actualizan. Una tienda en Flux corresponde al modelo (general) en MVVM. no está personalizado para ninguna vista específica. Por lo general, cuando las personas usan React y Flux, cada componente React realmente implementa el patrón MVVM. Cuando ocurre una acción, el modelo de vista llama al despachador y finalmente se actualiza de acuerdo con los cambios en la tienda, que es el modelo. No puede decir que cada componente implementa MVC porque en MVC solo el controlador puede actualizar el modelo de vista.


2

mvc es del lado del servidor y mvvm es del lado del cliente (navegador) en el desarrollo web.

la mayoría de las veces javascript se usa para mvvm en el navegador. Hay muchas tecnologías del lado del servidor para mvc.


1

En resumen: en MVC Controler conoce la vista (de controles), mientras que en MVVM, ViewModel no sabe quién la consume. ViewModel expone sus propiedades y acciones observables a quien pueda estar interesado en usarlo. Ese hecho facilita las pruebas ya que no hay referencia a la interfaz de usuario dentro de ViewModel.


1

Modelo-Vista-Controlador (generalmente conocido como MVC ) es un patrón de diseño de software comúnmente utilizado para desarrollar interfaces de usuario que dividen la lógica del programa relacionado en tres elementos interconectados. Esto se hace para separar las representaciones internas de información de las formas en que el usuario presenta y acepta la información. Siguiendo el patrón arquitectónico MVC desacopla estos componentes principales permitiendo la reutilización de código y el desarrollo paralelo.

Utilizado tradicionalmente para interfaces gráficas de usuario de escritorio (GUI), este patrón se ha vuelto popular para diseñar aplicaciones web. Los lenguajes de programación populares como JavaScript, Python, Ruby, PHP, Java y C # tienen marcos MVC que se utilizan en el desarrollo de aplicaciones web directamente.

Modelo

El componente central del patrón. Es la estructura de datos dinámicos de la aplicación, independiente de la interfaz de usuario. Gestiona directamente los datos, la lógica y las reglas de la aplicación.

Ver

Cualquier representación de información como un gráfico, diagrama o tabla. Son posibles múltiples vistas de la misma información, como un gráfico de barras para la administración y una vista tabular para los contadores.

Controlador

Acepta entradas y las convierte en comandos para el modelo o la vista.

Además de dividir la aplicación en estos componentes, el diseño modelo-vista-controlador define las interacciones entre ellos.

El modelo es responsable de administrar los datos de la aplicación. Recibe la entrada del usuario desde el controlador.

La vista significa una presentación del modelo en un formato particular.

El controlador responde a la entrada del usuario y realiza interacciones en los objetos del modelo de datos. El controlador recibe la entrada, opcionalmente la valida y luego pasa la entrada al modelo. ingrese la descripción de la imagen aquí

Model – View – ViewModel (MVVM) es un patrón arquitectónico de software.

MVVM facilita la separación del desarrollo de la interfaz gráfica de usuario, ya sea a través de un lenguaje de marcado o código GUI, del desarrollo de la lógica de negocios o la lógica de back-end (el modelo de datos). El modelo de vista de MVVM es un convertidor de valor, lo que significa que el modelo de vista es responsable de exponer (convertir) los objetos de datos del modelo de tal manera que los objetos se puedan administrar y presentar fácilmente. A este respecto, el modelo de vista es más modelo que una vista y maneja la mayoría, si no toda, la lógica de visualización de la vista. El modelo de vista puede implementar un patrón de mediador, organizando el acceso a la lógica de fondo alrededor del conjunto de casos de uso admitidos por la vista.

MVVM es una variación del patrón de diseño del Modelo de presentación de Martin Fowler. MVVM abstrae el estado y el comportamiento de una vista de la misma manera, pero un Modelo de Presentación abstrae una vista (crea un modelo de vista) de una manera que no depende de una plataforma de interfaz de usuario específica.

MVVM fue inventado por los arquitectos de Microsoft Ken Cooper y Ted Peters específicamente para simplificar la programación basada en eventos de las interfaces de usuario. El patrón se incorporó a Windows Presentation Foundation (WPF) (sistema de gráficos .NET de Microsoft) y Silverlight (derivado de la aplicación de Internet de WPF). John Gossman, uno de los arquitectos de Microsoft WPF y Silverlight, anunció MVVM en su blog en 2005.

Model – View – ViewModel también se conoce como model – view – binder, especialmente en implementaciones que no involucran la plataforma .NET. ZK (un marco de aplicación web escrito en Java) y KnockoutJS (una biblioteca de JavaScript) usan model-view-binder. ingrese la descripción de la imagen aquí

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.