No acabo de entender muy bien la diferencia entre MVC y MVVM

Question

Entiendo que el objetivo de MVC es el de independizar las vistas con respecto al controlador.

Como he leído que dicen por ahí que MV es un contenedor de las clases del módelo o que instancia ese módelo. ¿Relegando a la ejecución de las clases de negocio al propio modelo?

La diferencia entonces sera que el controlador no sabe nada de las clases ni propiedades del modelo ya que es este el que instancia llamadas a las clases modelo. Que devuelven al controlador y el se encarga de ejecutar la lógica de negocio y transformarlas.

por favor un cable con esto..

Answer 1



MVC significa Modelo Vista Controlador, porque en este patrón de diseño se separan los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. Cuando la lógica de negocio realiza un cambio, es necesario que ella sea la que actualiza la vista.  

El patron MVC se ve frecuentemente en paginas Web, ahora el comportamiento ASP.NET MVC es de la siguiente manera la petición llega desde el servidor web y es manejado directamente por el Contralor. El controlador determina la vista de su caso, que se llena con los modelos. El controlador entonces libera estos casos en el sistema subyacente que muestra el resultado al cliente. Se puede ver entonces que el controlador es el primero y el último en actuar.

MVVM significa Modelo Vista VistaModelo, porque en este patrón de diseño se separan los datos de la aplicación, la interfaz de usuario pero en vez de controlar manualmente los cambios en la vista o en los datos, estos se actualizan directamente cuando sucede un cambio en ellos, por ejemplo si la vista actualiza un dato que está presentando se actualiza el modelo automáticamente y viceversa.

En MVVM, la interfaz de usuario (la vista), se enfrenta al usuario y toma la entrada del usuario directamente. En la vista, los comandos dentro de la ViewModel (que es el DataContext de la vista) son provocados por esta actividad. El Control de los flujos del ViewModel interpreta lo que la vista ha enviado y prepara a sus modelos. Después del control fluye de nuevo a la vista que se actualiza de acuerdo a los cambios en los modelos. Si una nueva vista requiere informacion, el ViewModel comunica con el NavigationService (o cualquier otro método de navegación utiliza por la aplicación), que es de la competencia de la Vista o UI.  Se puede ver que el modelo de vista no es el primero y el último en actuar, la vista juega un papel mucho mayor que en MVC.

La arquitectura de WPF / Silverlight es la razón por la cual se hacen las cosas de esta manera. El comando, las infraestructuras de enlace y la navegación no se puede controlar / reemplazado por el controlador, sino que se integra perfectamente con la interfaz de usuario. Así que el controlador debe sentarse debajo de la vista y tomar un papel más pasivo.

Basicamente depende para que quieres tecnologia deseas desarrollar tu aplicacion e implementar la mas indicada para ella, Web el camino es MVC o MVP, y para WPF, Silverlight y Metro Style MVVM. Esas son mis recomendaciones y espero te sea de utilidad.

Cualquier otra duda, quedo al pendiente.





---

© Juan Manuel Rosas Salazar

Answer 2

Entiendo entonces que en MVVM la vista es capaz de actulizarse por si sola grácias a interacturar con la vista modelo.

Osea si MVC yo tengo una vista que me saque un listado de alumnos por nombre y apellido, y en un momento dado necesito que además se me muestre la nota de cada uno. Yo tendría que retocar esta vista para que incluya ese nuevo campo nota.

En MVVM no haría falta actualizar esta vista el cambio en el módelo incluyendo el campo nota lo cogería directamente y lo actualizaría en la vista.

¿Es así?, gracias por la ayuda, compañero

Esto es lo que entiendo leyendo:

MVC

Cuando la lógica de negocio realiza un cambio, es necesario que ella sea la que actualiza la vista.  

MVVM 

la interfaz de usuario pero en vez de controlar manualmente los cambios en la vista o en los datos, estos se actualizan directamente cuando sucede un cambio en ellos, por ejemplo si la vista actualiza un dato que está presentando se actualiza el modelo automáticamente y viceversa.

Answer 3

Como lo mencionas la vista es capaz se debe de actualizar sola asi como es la que debe de controlar todos sus eventos sean de animacion o de otro tipo, de tal forma que por eso los objetos de Silverlight utilizan la propiedad Binding Element. En esta propiedad se puede aplicar el modo a dos vías (Mode TwoWay), el cual fuerza el flujo de datos compartido entre el elemento origen y el destino sobre ambas vías. Lo que permite que la propiedad enlazada sea bidireccional en lugar de direccional ó OneWay el cual es el valor por defecto de la propiedad Mode. Al existir un enlace bidireccional el elemento destino será actualizado si surgen cambios en la propiedad enlazada del elemento origen y a subes esta propiedad será actualizada si surgen cambios en elemento destino.

Algunos links de informacion sobre comparacion de MVC y MVVM, que pueden ser de tu interes:

MVVM vs MVC

MVC vs MVVM

MVC vs MVVM

MVC vs MVVM

Saludos

---

© Juan Manuel Rosas Salazar

Answer 4

Muchas gracias Juan, 

Considero muy útil esta información para los que venimos de otros lenguajes como Java.

Answer 5

Buenas tardes.

Quisiera aportar lo siguiente a tu explicación sobre las diferencias en MVVM y MVC:

Ambos son patrones se encuentran dentro de la capa de presentación de un sistema, ya que , a su forma, cada uno intenta desacoplar la vista respecto del backend. Los controladores de MVC, a mi criterio, no deben aplicar lógica de negocio, así como tampoco el ModeloVista con sus comandos. La finalidad de ambos es coordinar y separar la representación visual de los modelos respecto de los modelos en sí (ej.: una colección de objetos es el modelo y en la vista deben presentarse como grillas o un listbox) además de realizar las modificaciones sobre la vista cuando corresponda.

Lo que sí debe suceder es que para la modificación del modelo (en ambos patrones) se mande a ejecutar el conjunto de reglas de negocio que no reside dentro del mismo controlador (por ejemplo, en un web service o en una dll destinada a tal fin). De esta manera realmente estás trabajando con bajo acoplamiento y alta cohesión entre los componentes del sistema.

Me parece pertinente hacer esta aclaración dado que es frecuente que los programadores asocien MVC con un modelo en 3 capas (presentación, negocio y datos) cuando realmente no es así.

Por último quisiera agregar también que MVVM no se limita a WPF y Silverlight ya que, al igual que MVC, no dependen de una tecnología en particular (aunque abunden ejemplos de implementación en .NET).

Existen librerías como Knockuoutjs que permiten aplicar MVVM a cualquier tecnología (PHP, ASP.NET WebForms o ASP.NET MVC).

Les dejo el siguiente video donde se demuestra la aplicación de la librería en un entorno ASP.NET MVC

http://www.youtube.com/watch?v=hHJxP9zll14

Saludos cordiales!

---

My inglish is not very good looking

Answer 6

Diego, muy claro lo suyo. Te tengo una pregunta. Quisiera trabajar lo más desacoplado posible y no se si este enfoque es el correcto. Tendré un componente que se encargue del acceso a datos vía EntityFramework y utilizaré los DTO que crea por medio de TTL. Luego la capa de negocios será un WS (qué me recomiendas usar?). O es preferible una dll aparte que luego se acceda o directamente o por medio de un WS si necesito conectarme remotamente? 

Si la aplicación es WEB y me decido por MVC 4, por ejemplo, los controladores acceden a la capa de negocios, y que hay del modelo? Serian representaciones de los DTO directamente, o vistas sobre estos?

Y para complicar los conceptos aún un poco más, si en el cliente uso MVVM, por ejemplo Knockout JS, y acceso los datos vía WebApi, deja de tener sentido el MVC4? o lo utilizo para servir las páginas o al menos la primer página?

Un poco de luz por favor! :)

Abrazo, y gracias por adelantado.