model view controller - que - ¿Cuál es la diferencia entre MVC y MVVM?

mvvm xamarin (22)

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

MVC / MVVM no es una opción de uno u otro .

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

Para ASP.Net, MVVM se utiliza para enlazar datos de forma bidireccional dentro de las vistas. Esto suele ser una implementación del lado del cliente (por ejemplo, utilizando Knockout.js). Por otro lado, MVC 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 suposición, que con frecuencia surgió de este patrón, fue que ViewModel simplemente reemplazó el controlador en MVC (como si pudiera sustituir VM por C en el acrónimo y todo quedaría perdonado) ...

El ViewModel no necesariamente reemplaza la necesidad de controladores separados.

El problema es que para ser verificable de forma independiente *, y especialmente reutilizable cuando es necesario, un modelo de vista no tiene idea de qué vista lo muestra, pero lo más importante es que no sabe 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 una prueba de unidad. La máquina virtual se convierte en un contenedor tonto que requiere pocas pruebas, si es que 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 ser simple.

Incluso en MVVM, los controladores normalmente contendrán toda la lógica de procesamiento y decidirán qué datos mostrar en qué vistas usar qué modelos de vista.

De lo que hemos visto hasta ahora, el principal beneficio del patrón de ViewModel es eliminar el código del código XAML para que la edición de XAML sea una tarea más independiente . Todavía creamos controladores, cuando sea necesario, para controlar (sin intenciones de palabra) 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 vienen los datos.
Los modelos de vista tienen una cierta 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, 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 a ViewModel para que ViewModel sea realmente reutilizable.

También notamos que el marco del código gen de Sculpture 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 de los casos de uso.

No asuma que los controladores se vuelven obsoletos por los modelos View.

Comencé un blog sobre este tema que agregaré cuando sea posible . Hay problemas con la combinación de 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 veré 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 poca información de estado (es decir, sobrecarga de memoria). Esto hace que las aplicaciones requieran mucho menos memoria que las soluciones en las que se deben conservar los modelos de visualización y es ideal para ciertos tipos de desarrollo móvil (por ejemplo, Windows Mobile con Silverlight / Prism / MEF). Por supuesto, esto depende del tipo de aplicación, ya que es posible que aún deba conservar las VM en caché ocasionales para mejorar la capacidad de respuesta.

Nota: Esta publicación ha sido editada varias veces y no se dirigió específicamente a la pregunta restringida, así que actualicé la primera parte para cubrir eso también. Gran parte de la discusión, en los comentarios a continuación, se relaciona solo con ASP.Net y no con el panorama más amplio. Esta publicación estaba destinada a cubrir el uso más amplio de MVVM en Silverlight, WPF y ASP.Net e intenta evitar que las personas reemplacen los controladores con ViewModels.

Inyectar ViewModels fuertemente tipados en la vista usando MVC

El controlador es responsable de actualizar el ViewModel e inyectarlo en la Vista. (para obtener solicitudes)
El ViewModel es el contenedor para DataContext y el estado de la vista, como el último elemento seleccionado, etc.
El modelo contiene entidades de base de datos y está muy cerca del esquema de base de datos, ya que realiza las consultas y el filtrado. (Me gusta EF y LINQ para esto)
El modelo también debe considerar los repositorios y / o la proyección de resultados en tipos fuertes (EF tiene un método excelente ... EF.Database.Select (cadenas de consulta, parámetros) para el acceso directo de ADO para inyectar consultas y recuperar tipos fuertes. es un argumento lento. EF no es lento !
El ViewModel obtiene los datos y hace las reglas de negocio y la validación
El controlador en post-back llamará el método de ViewModel Post y esperará los resultados.
El controlador inyectará el Viewmodel recién actualizado a la Vista. La vista utiliza solo el enlace de tipo fuerte .
La vista simplemente representa los datos y envía los eventos al controlador. (ver ejemplos abajo)
MVC intercepta la solicitud de entrada y la enruta al controlador adecuado con un tipo de datos sólido

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

Supongamos 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 se instancia automáticamente por los mecanismos de enlace MVC. ¡Como resultado, nunca tendrá que bajar a 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 usted pretende, debe tener un CTOR nulo definido que intialice las cosas que no se devuelven en la publicación. La publicación posterior también debe devolver los pares nombre / valor para aquellas cosas que cambiaron. Si faltan pares de nombre / valor, el motor de enlace MVC hace lo correcto, ¡simplemente no es nada! Si esto sucede, es posible que te encuentres diciendo "Estoy perdiendo datos en los respaldos de publicaciones" ...

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

Creo que la forma más sencilla de entender lo que se supone que significan estas siglas es olvidarse de ellas por un momento. En su lugar, piense en el software con el que se 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 la forma en que se popularizó a las masas de desarrolladores 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«, asumamos que la base de datos más el código de la interfaz. Para »páginas HTML«, asumamos plantillas HTML más código de procesamiento de plantillas. Para »code inbetween«, supongamos que el usuario del mapeo de códigos hace clic en acciones, posiblemente afectando a la base de datos, lo que definitivamente hace que se muestre otra vista. Eso es todo, al menos con el propósito de esta comparación.

Retengamos una característica de este material 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 prefiere, 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 esta forma web, a pesar de estar de moda, fue horriblemente atrasada 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 un tipo de cliente, un cliente para documentos). Son clientes llenos de inteligencia, llenos de conocimiento sobre sus datos. Son con estado. Cachean los datos que están manejando en la memoria. No hay tal basura como una recarga de página completa.

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

MVC = modelo, controlador, vista = esencialmente comunicación unidireccional = interactividad deficiente
MVVM = modelo, controlador, caché, vista = comunicación bidireccional = interactividad rica

Podemos ver que con Flash, Silverlight y, lo que es más importante, Javascript, la web ha adoptado MVVM. Los navegadores ya no pueden ser legítimamente llamados thin clients. Mira su programabilidad. Mira su consumo de memoria. Mira toda la interactividad de Javascript en las páginas web modernas.

Personalmente, me parece que esta teoría y el negocio de las siglas son más fáciles 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.

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

MVC (Model View Controller)

Modelos: Los modelos contienen información de datos. No llama ni usa el controlador y la vista. Contiene la lógica de negocio 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.
Controlador: Actúa como la conexión entre vista y modelo. Ver llamadas Controlador y Controlador llama al modelo. Básicamente informa al modelo y / o la vista para cambiar según corresponda.
Ver: Ofertas con la parte UI. Interactúa con el usuario.

MVVM (Modelo Vista Modelo Vista)

ViewModel :

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

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 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 a todos los elementos de la interfaz de usuario.

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

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

Puede que esté equivocado, pero no estoy seguro de que MVVM realmente haga que el controlador entre en la mezcla. Me parece que el concepto está más en línea con: http://martinfowler.com/eaaDev/PresentationModel.html . Creo que la gente elige combinarlo con MVC, no que esté integrado en el patrón.

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.

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

Si no estoy lleno de basura, me sorprende que nadie haya creado un híbrido, donde su máquina virtual no sea más que un proxy M, y C ofrece todas las funciones.

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 empuje principal de la arquitectura del Modelo / Vista / ViewModel parece ser que encima de los datos ("el Modelo"), hay otra capa de componentes no visuales ("el ViewModel") que mapea 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 vincula la Vista, no el Modelo directamente.

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.

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.
Vista : una aplicación normalmente se compone de varias páginas de IU. Cada página que se muestra al usuario es una vista en la terminología de MVVM. La vista es el código XAML que se usa para definir y diseñar lo que el usuario ve. Los datos del modelo se muestran al usuario, y es el trabajo de ViewModel alimentar a la UI con estos datos según el 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 muestra al usuario una imagen en particular.
ViewModel : ViewModel vincula el modelo de datos, o simplemente el modelo, a la interfaz de usuario o las 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 pueden enlazar la interfaz de usuario de XAML, o las vistas. Por ejemplo, en una aplicación para compartir imágenes, el ViewModel expondría una lista de álbumes, y para cada álbum expone 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 las muestra al usuario.

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

El controlador se sustituye por un ViewModel . El ViewModel se encuentra debajo de la capa UI. El ViewModel expone los datos y los objetos de comando que necesita la vista. Podría pensar en esto como un objeto contenedor al que la vista va para obtener sus datos y acciones. El ViewModel extrae sus datos del modelo.

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

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 pasa a ser 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 toda la arquitectura es idéntica).

MVVM es un entorno reactivo, lo que significa que normalmente escribe código (como activadores) 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 propiedad cambiado) y la Vista reacciona según los disparadores 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 el estado basado en valores. Además, los ViewModels son sin estado con muy poca lógica, y los Modelos son el estado con una lógica esencialmente cero, ya que solo deben mantener el estado. Describo esto como estado de aplicación (Modelo), traductor de estado (ViewModel) y luego el estado visual / interacción (Ver).

En una aplicación del lado del cliente o de escritorio de MVC, debe tener un modelo, y el controlador debe usar el modelo. Basado en el Modelo, el controlador modificará la Vista. Las vistas suelen estar 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 al revés en el servidor, ya que el Controlador administra los Modelos y pasa los Modelos a una Vista seleccionada. La Vista luego se llena con datos basados en el modelo y tiene su propia lógica (generalmente otro conjunto de MVC como el hecho con AngularJS). La gente discutirá y confundirá esto con la aplicación MVC e intentará hacer ambas cosas, momento en el que el mantenimiento del proyecto 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 la Vista en el código que está 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 debe vivir en una Vista es lo que se necesita para crear y ejecutar a través de la Interfaz que está usando. 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 siempre que la Vista active la acción Enviar. Si lo hace correctamente, siempre puede orientarse fácilmente en una aplicación web o local de MVC.

MVVM es personalmente mi favorito ya que es completamente reactivo. Si un modelo cambia de estado, el ViewModel escucha y traduce ese estado y ¡ya está! La Vista luego escucha 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: Digamos que desea que un menú se deslice al presionar un botón. En MVC tendrás una acción MenuPressed en tu interfaz. El Controlador sabrá cuándo hace clic en el botón Menú y luego le indica a la Vista que se deslice en el Menú basándose en otro método de Interfaz como SlideMenuIn. ¿Un viaje de ida y vuelta por qué? 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 con la Vista sin hacer nada a menos que el Controlador lo indique. SIN EMBARGO; en MVVM, el menú de diapositivas en animación debe estar integrado y ser genérico y, en lugar de decirle que lo haga, se basará en algún valor. Entonces escucha el ViewModel y cuando el ViewModel dice, IsMenuActive = true (o sin embargo) la animación para eso ocurre. Ahora, dicho esto, quiero hacer otro punto REALMENTE CLARO y POR FAVOR, preste atención. IsMenuActive es probablemente BAD MVVM o diseño de ViewModel. Al diseñar un ViewModel, 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 manejar el menú? Cuando los datos tienen sentido así es como. Por lo tanto, 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 que se abrirá a través del disparador, si no, entonces se sabe que se debe ocultar a través del disparador. Simplemente tiene datos para el menú o no en el 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.

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

Así que ... cosas a tener en cuenta para hacer esto bien. Decida por adelantado cómo diseñar su aplicación y STICK TO IT.

Si hace MVC, lo cual es genial, entonces asegúrese de que el Controlador sea manejable y tenga el control total de su Vista. Si tiene una Vista grande, considere agregar controles a la Vista que tengan diferentes Controladores. SOLO NO HAGA esos controladores a diferentes controladores. Muy frustrante de mantener. Tómese un momento y diseñe las cosas por separado de manera que funcionen 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 es Ver ← Controlador → Modelo o con ASP.NET (no me refiero) 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 Controller in View en este punto es principalmente para referencia de punto final para saber dónde volver a pasar un modelo.

Si haces MVVM, bendigo a tu alma bondadosa, ¡pero tómate el tiempo para hacerlo CORRECTAMENTE! No utilice interfaces para uno. Deje que su vista decida cómo se verá en función de los valores. Juega con la vista con datos simulados. Si terminas teniendo una Vista que te muestra un Menú (según el ejemplo) aunque no lo quisieras en ese momento, entonces BUENO. La vista está funcionando como debería y reaccionando según los valores como debería. Simplemente agregue algunos requisitos más a su activador para asegurarse de que esto no suceda cuando el ViewModel esté en un estado traducido particular o ordene que el ViewModel vacíe este estado. En su ViewModel NO elimine esto con la lógica interna 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 el ViewModel. Y, finalmente, el modelo debería permitirle cambiar y, probablemente, el estado de la tienda. 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 el 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 disparador. Todos los datos de la Vista pueden vincularse a ViewModel, por lo que todo puede ser dinámico, solo el Modelo y ViewModel no tienen ni idea de cómo reaccionará View al enlace. De hecho, el Modelo tampoco tiene idea de un ViewModel. Al configurar las dependencias, deben apuntar así y solo así Ver Ver → Modelo → Modelo (y una nota al margen aquí ... y esto probablemente también se discutirá, pero no me importa ... NO PASE EL MODELO para La VISTA. La Vista no debería ver un período modelo. Le doy a las ratas un crack que muestra la demo que has visto o cómo la has hecho, eso está mal.

Aquí está mi consejo final ... 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 una flexibilidad limitada a cero, mientras que el otro no tendrá control y una 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 la menor idea de lo que está haciendo el resto de la aplicación. Micro gestión vs gestión libre.

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

Al final del día, todos somos programadores y con esa anarquía vive dentro de nosotros cuando se codifica ... Por lo tanto, las reglas se romperán, las teorías cambiarán y todo esto terminará en el lavado de cerdos ... En los proyectos y en equipos grandes, realmente ayuda a acordar un patrón de diseño y aplicarlo. Un día hará que los pequeños pasos adicionales tomados al principio se conviertan en saltos y límites de ahorros más adelante.

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

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

Bueno, generalmente MVC se usa en desarrollo web y MVVM es más popular en desarrollo WPF / Silverlight. Sin embargo, a veces el archivo web puede tener una combinación 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 tu MVC también puede cambiar. En las aplicaciones complejas, nadie usa el Modelo puro. Es posible que tenga sentido utilizar un ViewModel como un "Modelo" de MVC y su Modelo real, básicamente, será parte de esta VM. Esto te da una capa de abstracción extra.

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

De hecho, en estos días, los sitios web simples y las aplicaciones web más grandes se construyen comúnmente con muchas bibliotecas populares como Bootstrap. Construido por Steve Sanderson, Knockout brinda 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, solo estas dos bibliotecas 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 una sola página .

De manera similar, un marco del lado del cliente moderno como Angular sigue el patrón MVC por convención, pero también agrega un Servicio. Curiosamente, se promociona como Modelo-Vista-Lo que sea (MVW). (Ver este post en Desbordamiento de pila ).

Además, con el auge de los marcos web progresivos como Angular 2, estamos viendo un cambio en la terminología y quizás un nuevo patrón arquitectónico donde los componentes forman parte de una vista o plantilla e interactúan con un servicio, todo lo cual puede incluirse en Módulo; y una serie de módulos conforman la aplicación.

Desde un punto de vista práctico, MVC (Model-View-Controller) 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 potente y parcialmente automatizado para llevar bases de datos, tablas y columnas a una página web, ya sea para una versión completa. 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 eran "hechos a mano" y después de mucho esfuerzo, uno tuvo la suerte de obtener modelos tan buenos como los que EF le da a uno "fuera". -De la caja". Desde el punto de vista práctico de la programación, MVC parece ser una buena opción porque brinda una gran cantidad de utilidades fuera de la caja, pero aún existe la posibilidad de que se agreguen campanas y silbidos.

El Controlador no es reemplazado por un ViewModel en MVVM, porque el ViewModel tiene una funcionalidad totalmente diferente a un Controlador. Aún necesita un controlador, porque sin un controlador su modelo, ViewModel y View no harán mucho ... En MVVM usted 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, el ViewModel es solo una adición al patrón MVC. Mueve la lógica de conversión (por ejemplo, convertir un objeto en una cadena) desde el Controlador al ViewModel.

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.

Tratando de arrojar algo de luz sobre lo anterior, inventé este guión que incluía 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 : Hey 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 View , ¿hay algún término de búsqueda en esa página?[ MVVM | MVP | MVC ]

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

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

Presentador : Gracias View , ... mientras estoy buscando el término de búsqueda en el modelo , muéstrale una barra de progreso [ MVP | MVC ]

(El presentador | 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 disparador en searchResultsListObservable, la Vista cree que debería mostrar alguna barra de progreso al usuario, ya que ViewModel no hablaría de eso)

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

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

Modelo : Hey ViewModel | Presentador | Controlador , déjame revisar… [ MVVM | MVP | MVC ]

(El modelo está realizando una consulta en 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 algún resultado disponible, Controlador. He creado una variable de campo en mi instancia y la he llenado con el resultado.Su nombre es "searchResultsList" [ MVC ]

(El presentador | Controlador agradece al modelo y vuelve a la vista ) [ MVP | MVC ]

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

Controlador : Gracias por esperar View , 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 : Cualquier observador en searchResultsListObservable notifica que existe esta nueva lista en formato presentable: [“Piano Teacher 2001 ″,“ Piano 1993 ”]. [ MVVM ]

Vista : Muchas gracias Presenter [ MVP ]

Vista : Gracias " Controlador " [ MVC ] (Ahora la vista se está cuestionando: ¿Cómo debo presentar los resultados del Modelo al usuario? ¿El año de producción de la película debe ser el primero o el último ...?)

Vista : Oh, hay un nuevo activador 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 here , comparando MVVM, MVP y MVC mediante la implementación de una aplicación de búsqueda de películas para Android.

MVVMC, o quizás MVC +, parece ser un enfoque viable para la empresa, así como un rápido desarrollo de aplicaciones. Si bien es bueno separar la IU 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 cierta medida. Usar la página como controlador anularía completamente el propósito de MVVM, 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 madura. Incluso en VB-6, la mayoría de nosotros probablemente detuvimos la codificación de la lógica empresarial en el evento Button y comenzamos a "transmitir" los comandos a un controlador, ¿verdad? Hace poco miré muchos marcos emergentes sobre ese tema; Mi favorito claramente es el enfoque de Magellan (en codeplex). ¡Feliz codificación!

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

Me sorprende que esta sea una respuesta altamente votada sin mencionar el origen de MVVM. MVVM es un término popular usado en la comunidad de Microsoft y se origina a partir del Modelo de presentación de Martin Fowler . Entonces, para entender 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.

Por lo que puedo decir, el MVVM se asigna al MV del MVC, lo que significa que en un patrón MVC tradicional, la V no se comunica directamente con el M. En la segunda versión del MVC, hay un enlace directo entre M y V. MVVM parece tomar todas las tareas relacionadas con la comunicación M y V, y acoplarlas para desacoplarlas 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 está totalmente explicado en MVVM. Este es el papel del controlador. Al eliminar estos aspectos de nivel inferior de los controladores, son más limpios y facilita la modificación del escenario de uso de la aplicación y la lógica empresarial, lo que también hace que los controladores sean más reutilizables.

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

En MVC, para cada vista en tu aplicación, tienes un modelo y un controlador, así que lo llamaría vista, ver modelo, ver controlador. El patrón no te 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 diablos la vista debe influir en el modelo de vista, por lo que generalmente la mayoría de los marcos solo incluyen la funcionalidad del controlador en el modelo de vista. Sin embargo, MVVM sí 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 de una vista específica.

Para demostrar la diferencia, tomemos el patrón de flujo. El patrón de flujo indica cómo deben comunicarse las diferentes vistas de la aplicación. Cada vista escucha una tienda y dispara acciones usando 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 es personalizado para ninguna vista específica. Por lo general, cuando las personas usan React y Flux, cada componente React implementa el patrón MVVM. Cuando ocurre una acción, el modelo de vista llama al despachador, y finalmente se actualiza según 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.Entonces, MVVM puede trabajar con Flux juntos (MVVM maneja la comunicación entre la vista y el modelo de vista, y Flux maneja la comunicación entre diferentes vistas), mientras que MVC no puede trabajar con Flux sin romper un principio clave.