Pregunta ¿Cuál es la diferencia entre MVC y MVVM?


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


1097
2018-03-20 20:09


origen


Respuestas:


MVC / MVVM no es un Cualquiera o elección.

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

Para ASP.Net, MVVM está acostumbrado a enlace bidireccional datos dentro de las vistas. Esta 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 abarcador y puede Aparecer para actuar como un reemplazo de MVC (u otros patrones de organización de software en responsabilidades separadas). Una suposición, que con frecuencia surgió de este patrón, fue que el ViewModel simplemente reemplazó el controlador en MVC (como si pudieras simplemente sustituir VM para C en el acrónimo y todos serían perdonados) ...

El ViewModel no 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 más importante no tengo idea 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. Luego, la máquina virtual se convierte en un contenedor tonto que requiere pocas pruebas, si las hay. Esto es algo 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 generalmente contienen toda la lógica de procesamiento y deciden qué datos mostrar en qué vistas usar qué modelos de vista.

De lo que hemos visto hasta ahora, el principal beneficio del patrón ViewModel es eliminar el código del código XAML detrás para hacer que la edición 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:

  • Puntos de vista mostrar una cierta forma de datos. No tienen idea de dónde provienen los datos.
  • ViewModels mantener una cierta forma de datos y comandos, no saben de dónde provienen los datos o el código, ni cómo se muestran.
  • Modelos mantener los datos reales (varios contexto, tienda 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 al ViewModel para que el ViewModel sea realmente reutilizable.

También notamos que Sculpture code-gen framework implementa MVVM y un patrón similar a Prism Y también hace un uso extensivo de los controladores para separar toda la lógica del caso de uso.

No suponga que los controladores están obsoletos por los modelos View.

He comenzado un blog sobre este tema que añadiré a medida que pueda. Existen problemas para 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 entraré en eso en artículos posteriores.

Un beneficio adicional de usar un modelo MVCVM es que solo los objetos del controlador deben existir en la memoria durante la vida de la aplicación y los controladores contienen principalmente código y pequeños datos de estado (es decir, una pequeña sobrecarga de memoria). Esto supone aplicaciones mucho menos intensivas en memoria que las soluciones donde se deben conservar los modelos de vista y es ideal para ciertos tipos de desarrollo móvil (por ejemplo, Windows Mobile utilizando Silverlight / Prism / MEF). Esto, por supuesto, depende del tipo de aplicación, ya que es posible que aún necesite retener las máquinas virtuales en caché ocasionales para la capacidad de respuesta.

Nota: Esta publicación se ha editado en numerosas ocasiones y no se ha dirigido específicamente a la pregunta restringida, por lo que he actualizado la primera parte para cubrirla también. Gran parte de la discusión, en los comentarios a continuación, se refiere solo a ASP.Net y no a una imagen más amplia. Esta publicación fue pensada para cubrir el uso más amplio de MVVM en Silverlight, WPF y ASP.Net e intentar evitar que las personas reemplacen los controladores con ViewModels.


578
2017-08-22 09:19



Creo que la manera 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 web temprana y el escritorio.

El primer acrónimo, MVC, se originó en la web. (Sí, puede haber estado allí antes, pero la web es cómo se popularizó entre las masas de desarrolladores web). Piense en la base de datos, las páginas HTML y el código entre ellas. Vamos a refinar esto solo un poco para llegar a MVC: Para »base de datos«, supongamos que la base de datos más el código de la interfaz. Para "páginas HTML", supongamos que las plantillas HTML más el código de procesamiento de la plantilla. Para el "código entre medias", supongamos que el usuario del mapeo de códigos hace clic en las acciones, lo que posiblemente afecte 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.

Retengamos una característica de esta web, no como lo 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 es, 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 camino web, a pesar de estar de moda, fue terriblemente atrasado en comparación con el escritorio. Las aplicaciones de escritorio son clientes gordos, o clientes ricos, si se quiere. (Incluso un programa como Microsoft Word puede considerarse como un tipo de cliente, un cliente de documentos). Son clientes llenos de inteligencia, llenos de conocimiento sobre sus datos. Ellos son estables. Almacenan en caché los datos que manejan en la memoria. No hay tanta basura como una recarga de página completa.

Y esta forma de escritorio rica es probablemente donde se originó el segundo acrónimo, MVVM. No te dejes engañar por las letras, por la omisión de la C. Los controladores todavía están allí. Ellos necesitan ser. Nada se elimina. Solo agregamos una cosa: statefulness, datos almacenados en caché en el cliente (y junto con su inteligencia para manejar esos datos). Esa información, esencialmente un caché en el cliente, ahora se llama »ViewModel«. Es lo que permite una rica interactividad. Y eso es.

  • MVC = modelo, controlador, vista = comunicación esencialmente unidireccional = poca interactividad
  • 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 a MVVM. A los navegadores ya no se les puede llamar legítimamente thin clients. Mira su programabilidad. Mire su consumo de memoria. Mire toda la interactividad de Javascript en páginas web modernas.

Personalmente, encuentro que esta teoría y el acrónimo de la empresa son más fáciles de entender al ver a qué se refiere en la realidad concreta. Los conceptos abstractos son útiles, especialmente cuando se demuestran en materia concreta, por lo que la comprensión puede cerrarse.


213
2018-02-13 14:11



MVVM  Model-View ViewModel es similar a MVC, Controlador de vista de modelo

El controlador es reemplazado por ViewModel. ViewModel se encuentra debajo de la capa de UI. ViewModel expone los datos y los objetos de comando que la vista necesita. Podría pensar en esto como un objeto contenedor que la vista utiliza para 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?


166
2018-03-20 20:18



En primer lugar, 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 impulso principal de la arquitectura Model / View / ViewModel parece ser que, además de los datos ("el Modelo"), hay otra capa de componentes no visuales ("ViewModel") 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.


85
2018-03-20 20:17



Usted puede ver una explicación del patrón MVVM en el entorno de Windows:

En el patrón de diseño Model-View-ViewModel, una aplicación se compone de tres componentes generales. enter image description here

  • Modelo: Esto representa el modelo de datos que consume su aplicación. Por ejemplo, en una aplicación para compartir fotos, esta capa podría 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 de MVVM. La vista es el código XAML utilizado para definir y personalizar lo que el usuario ve. Los datos del modelo se muestran al usuario, y es el trabajo de ViewModel alimentar la UI con estos datos en función del estado actual de la aplicación. Por ejemplo, en una aplicación para compartir fotos, las vistas serían la interfaz de usuario que muestra al usuario la lista de álbumes en el dispositivo, las imágenes de un álbum y quizás otra que muestre al usuario una imagen en particular.

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


44
2018-06-12 20:48



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

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


35
2018-05-21 11:38



Diferencia simple: (Inspirado por el curso Coursera AngularJS de Yaacov)

enter image description here

MVC (Controlador de vista de modelo)

  1. Modelos: Los modelos contienen información de datos. No llama ni usa Controller y View. Contiene la lógica comercial y formas de representar datos. Algunos de estos datos, de alguna forma, se pueden mostrar 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 el modelo y / o la vista para cambiar según corresponda.
  3. Ver: Se ocupa de la parte UI. Interactúa con el usuario.

MVVM (Modelo de vista de modelo)

ViewModel:

  1. Es la representación del estado de la vista.
  2. Tiene 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 lógica de negocios.
  5. Nunca le pide directamente a la vista que muestre nada.

17
2017-12-14 00:20



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


16
2018-03-27 21:22



El modelo de vista es un modelo "abstracto" para sus elementos de 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, probablemente en algún momento le haya resultado útil crear objetos modelo para reflejar el estado de su vista, por ejemplo, para mostrar y ocultar algunos cuadros de diálogo de edición, etc. En ese caso, está usando un modelo de vista.

El patrón MVVM es simplemente la generalización de esa práctica para 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 le impide usarlo con las caras del servidor de Java, por ejemplo.


13
2018-03-23 10:16



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

En un entorno controlado, debe 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 vistas y en lógica dinámica. La creación vive en el servidor y vidas dinámicas en el cliente. Esto se ve mucho con ASP.NET MVC combinado con AngularJS, mientras que el servidor creará una Vista y pasará en un Modelo y se lo enviará al cliente. El cliente entonces 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 se escribe un código (como desencadenadores) 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ó, funcionará en cualquier sistema en cualquier Vista con cualquier lenguaje de programación. No es específico de MS. El ViewModel dispara (por lo general, un evento que ha cambiado la propiedad) y la Vista reacciona a él en función de los desencadenantes que cree. Esto puede ser técnico, pero la conclusión es que View es sin estado y sin lógica. Simplemente cambia el estado en función de los valores. Además, ViewModels son apátridas con muy poca lógica, y los Modelos son el Estado con esencialmente cero lógica, ya que solo deberían mantener el estado. Lo describo como un estado de aplicación (Modelo), un traductor de estado (ViewModel) y luego el estado / interacción visual (Ver).

En una aplicación MVC de escritorio o cliente, debe tener un Modelo y el Modelo debe ser utilizado por el Controlador. Basado en 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 para MVC está ligeramente hacia atrás en el servidor cuando el Controlador gestiona los Modelos y pasa los Modelos a una Vista seleccionada. La Vista se llena con datos basados ​​en el modelo y tiene su propia lógica (generalmente otro conjunto de MVC como hecho con AngularJS). La gente discutirá y confundirá esto con la aplicación MVC y tratará de hacer ambas cosas, momento en el que mantener el proyecto eventualmente se convertirá en un desastre. SIEMPRE ponga la lógica y el control en una ubicación cuando use MVC. NO escriba lógica de visualización en el código detrás de la vista (o en la vista a través de JS para web) para acomodar datos de controlador o modelo. Deje que el controlador cambie la vista. La ÚNICA lógica que debe 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 la computadora de escritorio o en la página web (en el cliente), el Controlador debe manejar el proceso de envío siempre que la Vista active la acción Enviar. Si se hace correctamente, siempre se puede encontrar fácilmente una aplicación web o local de MVC.

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

Aquí hay un pequeño ejemplo: digamos que desea tener un menú deslizado en un botón presione. En MVC tendrá una acción de MenuPressed en su interfaz. El Controlador sabrá cuando haga clic en el botón Menú y luego le dirá a la Vista que se deslice en el Menú según otro método de Interfaz como SlideMenuIn. Un viaje redondo por qué razón? En caso de que el Controlador decida que no puede o quiere hacer otra cosa, es por eso. El Controlador debería estar a cargo de la Vista con la Vista sin hacer nada a menos que el Controlador así 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 indicarle 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 tiene lugar. Ahora, con eso dicho, quiero hacer que otro punto sea REALMENTE CLARO y POR FAVOR, presten atención. IsMenuActive probablemente sea BAD MVVM o el diseño de ViewModel. Al diseñar un modelo de vista, nunca debe suponer que una vista tendrá ninguna característica y solo pasará el estado del modelo traducido. De esta forma, 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 administrarí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 Modelos de Vista internos). Si esa lista tiene datos, entonces el Menú sabe que se abrirá a través del activador, si no, entonces sabe esconderse a través del activador. 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 forma, la Vista es completamente reactiva y genérica y se puede usar en muchas situaciones diferentes.

Todo esto probablemente no tiene ningún sentido si aún no está al menos un poco familiarizado con la arquitectura de cada uno y aprender 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, que es genial, asegúrate de que el Controlador sea manejable y que tengas el control total de tu Vista. Si tiene una Vista grande, considere agregar controles a la Vista que tengan Controladores diferentes. SIMPLEMENTE NO conecte esos controladores a diferentes controladores. Muy frustrante de mantener Tómese un momento y diseñe cosas por separado de manera que funcionen como componentes separados ... Y siempre deje que el Controlador indique al Modelo que confirme o persista el almacenamiento. La configuración de dependencia ideal para MVC es Ver ← Controlador → Modelo  o con ASP.NET (no me hagas comenzar) 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 saber de Controller in View en este punto es principalmente para referencia de punto final para saber dónde volver para pasar un modelo.

Si haces MVVM, bendigo tu alma amable, ¡pero tómate el tiempo para hacerlo bien! No use interfaces para uno. Deje que su vista decida cómo se verá en función de los valores. Juega con la vista con datos falsos. Si termina teniendo una Vista que le muestra un Menú (según el ejemplo) aunque no lo haya deseado en ese momento, entonces BUENO. Tu vista está funcionando como debería y reacciona según los valores que debería. Simplemente agregue unos cuantos requisitos más a su activador para asegurarse de que esto no ocurra cuando ViewModel se encuentre en un estado de traducción determinado o ordene ViewModel para vaciar 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 suponer que hay un menú o no en ViewModel. Y finalmente, el Modelo solo debería permitirle cambiar y probablemente almacenar el estado. Aquí es donde ocurrirá la validación y todo; 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 la Vista se dará cuenta de esto y mostrará información a través de otro desencadenador. Todos los datos en la Vista pueden vincularse al ViewModel, por lo que todo puede ser dinámico, solo el Modelo y ViewModel no tienen absolutamente ninguna idea sobre cómo reaccionará la Vista al enlace. Como cuestión de hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar dependencias deben señalar como tal y solo como tal Ver → Modelo de vista → Modelo  (y una nota al margen aquí ... y probablemente esto también se discuta, pero no me importa ... NO PASES EL MODELO a la vista. La vista no debería ver un período modelo. Le doy a las ratas crack qué demo que has visto o cómo lo has hecho, está mal.)

Aquí está mi último consejo ... Mira una aplicación MVC bien diseñada, pero muy simple, y haz 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 única fuente) mientras que un entorno reactivo se puede dividir en repositorios separados sin tener absolutamente ninguna idea de lo que está haciendo el resto de la aplicación. Gestión micro frente a gestión gratuita.

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 ... Entonces las reglas se romperán, las teorías cambiarán, y todo esto terminará en lavado de cerdos ... Pero cuando se trabaja en grandes proyectos y en equipos grandes, realmente ayuda ponerse de acuerdo en 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 pasos adelante de los ahorros.


11
2018-01-25 05:15