238 votos

¿Cuál es la diferencia entre los patrones de diseño MVC, MVP y MVVM en términos de codificación en c#?

Si buscamos en Google usando la frase "diferencias entre el patrón de diseño MVC, MVP y MVVM" entonces podemos obtener algunas URL's que discuten la diferencia entre el patrón de diseño MVC MVP & MVVM teóricamente como :

MVP

Se utiliza en situaciones en las que no es posible la vinculación a través de un "dataContext". Windows Forms es un ejemplo perfecto de esto. Para separar la vista del modelo, se necesita un presentador. Como la vista no puede vincularse directamente al presentador, la información debe pasarse a la vista a través de una interfaz (IView).

MVVM

Se utiliza en situaciones en las que es posible la vinculación a través de un "dataContext". ¿Por qué? Se eliminan las distintas interfaces IView para cada vista, lo que significa menos código que mantener. Algunos ejemplos donde MVVM es posible incluir proyectos WPF y javascript usando Knockout.

MVC

Se utiliza en situaciones en las que la conexión entre la vista y el resto del programa no está siempre disponible (y no se puede emplear efectivamente MVVM o MVP). Esto describe claramente la situación en la que una API web está separada de los datos enviados a los navegadores de los clientes. ASP.NET MVC de Microsoft es una gran herramienta para gestionar estas situaciones y proporciona un marco MVC muy claro


Pero no he encontrado ningún artículo que discuta la diferencia teóricamente junto con un código de ejemplo.

Sería muy bueno si consigo un artículo que discuta la diferencia entre estos 3 patrones de diseño (MVC, MVP & MVVM) junto con el código.

Me gustaría tener en mis manos el código fuente de 3 similares CRUD aplicaciones que han sido implementadas por estos tres patrones de diseño (MVC, MVP y MVVM). Para que pueda ir a través del código y entender cómo se debe escribir código para estos tres patrones de diseño (MVC, MVP & MVVM).

Así que si existe algún artículo que discute cómo el código se vería diferente para estos 3 patrones de diseño (MVC, MVP y MVVM) entonces por favor redirigirme a ese artículo.

125voto

Algunas diferencias básicas pueden escribirse en pocas palabras:

MVC:

El MVC tradicional es aquel en el que hay un

  1. Modelo: Actúa como modelo para los datos
  2. Vista : Trata de la vista al usuario que puede ser la UI
  3. Controlador: Controla la interacción entre el modelo y la vista, donde la vista llama al controlador para actualizar el modelo. La vista puede llamar a varios controladores si es necesario.

MVP:

Similar al MVC tradicional, pero el controlador es reemplazado por el presentador. Pero el Presentador, a diferencia del Controlador es responsable de cambiar la vista también. La vista normalmente no llama al presentador.

MVVM

La diferencia aquí es la presencia de View Model. Es una especie de implementación del patrón de diseño Observer, donde los cambios en el modelo se representan en la vista también, por el VM. Por ejemplo, si se cambia un deslizador, no sólo se actualiza el modelo, sino que también se actualizan los datos, que pueden ser un texto, que se muestran en la vista. Así que hay un enlace de datos de dos vías.

62voto

Uddhav Gautam Puntos 3422

MVC, MVP, MVVM

MVC (antiguo)

MVP (más modular por su bajo acoplamiento. El presentador es un mediador entre la vista y el modelo)

MVVM (Ya tiene un enlace bidireccional entre la VM y el componente de la UI, por lo que es más automatizado que el MVP) enter image description here

Otra imagen: enter image description here

45voto

taha027 Puntos 186

Gran explicación del enlace : http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx

Veamos primero el MVC

La entrada se dirige primero al Controlador, no a la vista. Esa entrada puede provenir de un usuario que interactúa con una página, pero también podría ser simplemente introducir una url específica en un navegador. En cualquier caso, es un Controlador con el que se interactúa para poner en marcha alguna funcionalidad.

Existe una relación de muchos a uno entre el Controlador y la Vista. Esto se debe a que un mismo controlador puede seleccionar diferentes vistas para ser renderizadas en función de la operación que se esté ejecutando.

Hay una flecha de ida desde el Controlador a la Vista. Esto se debe a que la Vista no tiene ningún conocimiento o referencia al controlador.

El Controlador sí devuelve el Modelo, por lo que hay conocimiento entre la Vista y el Modelo esperado que se le pasa, pero no el Controlador que lo sirve.

MVP - Model View Presenter

Ahora veamos el patrón del MVP. Se parece mucho a MVC, excepto por algunas distinciones clave:

La entrada comienza con la Vista, no con el Presentador.

Existe un mapeo uno a uno entre la Vista y el Presentador asociado.

La Vista contiene una referencia al Presentador. El Presentador también reacciona a los eventos que se activan desde la Vista, por lo que es consciente de la Vista a la que está asociado.

El Presentador actualiza la Vista basándose en las acciones solicitadas que realiza en el Modelo, pero la Vista no es consciente del Modelo.

MVVM - Modelo Vista Vista Modelo

Así que con los patrones MVC y MVP frente a nosotros, vamos a ver el patrón MVVM y ver qué diferencias tiene:

La entrada comienza con la Vista, no con el Modelo de la Vista.

Mientras que la Vista tiene una referencia al Modelo de la Vista, el Modelo de la Vista no tiene información sobre la Vista. Por eso es posible tener un mapeo de uno a varios entre varias Vistas y un Modelo de Vista incluso entre tecnologías. Por ejemplo, una Vista WPF y una Vista Silverlight pueden compartir el mismo Modelo de Vista.

8voto

David Osborne Puntos 2058

Este debería ser un buen comienzo. En realidad, la "plataforma" elegida también desempeña un papel importante en el uso de estos patrones. Por ejemplo, MVVM es naturalmente adecuado para WPF, mientras que MVP funciona bien con Windows Forms. ASP.Net MVC habla por sí mismo.

3voto

Tarun A Puntos 352

MVP:

Ventajas:

El presentador estará presente entre el modelo y la vista. El presentador obtendrá los datos del modelo y manipulará los datos como la vista quiera y se los dará a la vista y la vista es responsable sólo de la representación.

Desventajas:

1)No podemos usar el presentador para múltiples módulos porque los datos están siendo modificados en el presentador como se desea por una clase de vista.

3)Rompiendo la arquitectura limpia porque el flujo de datos debería ser sólo hacia afuera pero aquí los datos están regresando del presentador a la Vista.

MVC:

Ventajas:

Aquí tenemos un controlador entre la vista y el modelo. Aquí la solicitud de datos se hará desde el controlador a la vista, pero los datos serán enviados de vuelta a la vista en forma de interfaz, pero no con el controlador.

Desventajas:

La manipulación de datos debe ser realizada por la vista como quiera y esto será un trabajo extra en el hilo de la interfaz de usuario que puede afectar a la representación de la interfaz de usuario si el procesamiento de datos es más.

MVVM:

Después de anunciar los componentes arquitectónicos, tenemos acceso a ViewModel que nos proporciona la mayor ventaja, es decir, es consciente del ciclo de vida, por lo que no notificará los datos si la vista no está disponible. Es una arquitectura limpia porque el flujo es sólo en modo de avance y los datos serán notificados automáticamente por LiveData. Por lo tanto, es la arquitectura recomendada por Android.

Incluso MVVM tiene un desventaja . Dado que es un ciclo de vida consciente de algunos conceptos como la alarma o el recordatorio debe venir fuera de la aplicación, por lo que en este escenario no podemos utilizar MVVM.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X