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

¿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?

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.

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.

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?

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.

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.

• 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.