¿Qué son MVP y MVC y cuál es la diferencia?


2133

Al mirar más allá de la forma RAD (arrastrar y soltar) de construir interfaces de usuario, muchas herramientas lo alientan a encontrar tres patrones de diseño llamados Model-View-Controller , Model-View-Presenter y Model-View-ViewModel . Mi pregunta tiene tres partes:

  1. ¿Qué problemas abordan estos patrones?
  2. ¿En qué se parecen?
  3. ¿En qué se diferencian?


2
IDK, pero supuestamente para el MVC original, estaba destinado a ser utilizado en pequeños. Cada botón, etiqueta, etc. tenía su propia vista y objeto de controlador, o al menos eso es lo que afirma el tío Bob. Creo que estaba hablando de Smalltalk. Busque sus charlas en YouTube, son fascinantes.
still_dreaming_1

MVP agrega una capa adicional de indirección al dividir el controlador de vista en una vista y un presentador ...
the_prole

2
La principal diferencia es que en MVC el controlador no pasa ningún dato del modelo a la vista. Simplemente notifica a la Vista para obtener los datos del propio Modelo. Sin embargo, en MVP, no hay conexión entre la Vista y el Modelo. El presentador mismo obtiene todos los datos necesarios del modelo y los pasa a la vista para mostrar. Más sobre esto junto con una muestra de Android en todos los patrones de arquitectura está aquí: digigene.com/category/android/android-architecture
Ali Nem

Se llaman patrones arquitectónicos, no patrones de diseño . Si quieres saber la diferencia,
mira

Respuestas:


1997

Modelo-Vista-Presentador

En MVP , el presentador contiene la lógica de negocios de la interfaz de usuario para la vista. Todas las invocaciones del delegado Ver directamente al Presentador. El presentador también se desacopla directamente de la vista y se comunica con él a través de una interfaz. Esto es para permitir la burla de la Vista en una prueba unitaria. Un atributo común de MVP es que tiene que haber mucho despacho bidireccional. Por ejemplo, cuando alguien hace clic en el botón "Guardar", el controlador de eventos delega al método "OnSave" del presentador. Una vez que se completa el guardado, el Presentador volverá a llamar a la Vista a través de su interfaz para que la Vista pueda mostrar que el guardado se ha completado.

MVP tiende a ser un patrón muy natural para lograr presentaciones separadas en formularios web. La razón es que la Vista siempre se crea primero mediante el tiempo de ejecución ASP.NET. Puede encontrar más información sobre ambas variantes .

Dos variaciones principales

Vista pasiva: la vista es lo más tonta posible y contiene casi cero lógica. El presentador es un intermediario que habla con la vista y el modelo. La vista y el modelo están completamente protegidos el uno del otro. El Modelo puede generar eventos, pero el Presentador se suscribe a ellos para actualizar la Vista. En la Vista pasiva no hay enlace de datos directo, en cambio, la Vista expone las propiedades del configurador que el Presentador utiliza para configurar los datos. Todo el estado se administra en el Presentador y no en la Vista.

  • Pro: superficie de máxima capacidad de prueba; separación limpia de la vista y el modelo
  • Con: más trabajo (por ejemplo, todas las propiedades del configurador) ya que usted mismo está haciendo todos los enlaces de datos.

Controlador supervisor: el presentador maneja los gestos del usuario. La vista se une al modelo directamente a través del enlace de datos. En este caso, es el trabajo del presentador pasar el modelo a la vista para que pueda vincularse a él. El presentador también contendrá lógica para gestos como presionar un botón, navegación, etc.

  • Pro: al aprovechar el enlace de datos, se reduce la cantidad de código.
  • Con: hay menos superficie comprobable (debido al enlace de datos), y hay menos encapsulación en la Vista, ya que habla directamente con el Modelo.

Modelo-Vista-Controlador

En el MVC , el controlador es responsable de determinar qué vista mostrar en respuesta a cualquier acción, incluso cuando se carga la aplicación. Esto difiere de MVP, donde las acciones se enrutan a través de la Vista al Presentador. En MVC, cada acción en la Vista se correlaciona con una llamada a un Controlador junto con una acción. En la web, cada acción implica una llamada a una URL en el otro lado del cual hay un controlador que responde. Una vez que el controlador haya completado su procesamiento, devolverá la vista correcta. La secuencia continúa de esa manera a lo largo de la vida de la aplicación:

    Acción en la vista
        -> Llamar al controlador
        -> Lógica del controlador
        -> El controlador devuelve la Vista.

Otra gran diferencia sobre MVC es que la Vista no se une directamente al Modelo. La vista simplemente se representa y es completamente apátrida. En las implementaciones de MVC, la Vista generalmente no tendrá ninguna lógica en el código subyacente. Esto es contrario al MVP donde es absolutamente necesario porque, si la Vista no delega en el Presentador, nunca se llamará.

Modelo de presentación

Otro patrón a tener en cuenta es el Modelo de presentaciónmodelo. En este patrón no hay presentador. En cambio, la vista se une directamente a un modelo de presentación. El modelo de presentación es un modelo diseñado específicamente para la vista. Esto significa que este modelo puede exponer propiedades que uno nunca pondría en un modelo de dominio, ya que sería una violación de la separación de preocupaciones. En este caso, el modelo de presentación se une al modelo de dominio y puede suscribirse a eventos provenientes de ese modelo. La Vista luego se suscribe a los eventos que provienen del Modelo de presentación y se actualiza en consecuencia. El Modelo de presentación puede exponer comandos que la vista usa para invocar acciones. La ventaja de este enfoque es que esencialmente puede eliminar el código subyacente por completo ya que el PM encapsula completamente todo el comportamiento de la vista.Modelo-Vista-VistaModelo .

Hay un artículo de MSDN sobre el Modelo de presentación y una sección en la Guía de aplicación compuesta para WPF (antiguo Prisma) sobre Patrones de presentación separados


27
¿Puedes por favor aclarar esta frase? Esto difiere de MVP, donde las acciones se enrutan a través de la Vista al Presentador. En MVC, cada acción en la Vista se correlaciona con una llamada a un Controlador junto con una acción. Para mí, parece lo mismo, pero estoy seguro de que estás describiendo algo diferente.
Panzercrisis

16
@ Panzercrisis No estoy seguro de si esto es lo que quiso decir el autor, pero esto es lo que creo que intentaban decir. Como esta respuesta, stackoverflow.com/a/2068/74556 menciona, en MVC, los métodos del controlador se basan en comportamientos; en otras palabras, puede asignar múltiples vistas (pero el mismo comportamiento) a un solo controlador. En MVP, el presentador se acopla más cerca de la vista y, por lo general, da como resultado una asignación que está más cerca de uno a uno, es decir, una acción de vista se asigna al método del presentador correspondiente. Por lo general, no asignaría las acciones de otra vista al método de otro presentador (desde otra vista).
Dustin Kendall

2
Tenga en cuenta que a MVC menudo es utilizado por marcos web como Laravel, donde las solicitudes de URL recibidas (tal vez hechas por los usuarios) son manejadas por el Controllery el HTML generado por el Viewes enviado al cliente - Entonces, Viewes parte del backend y el el usuario nunca puede acceder a él directamente, y si experimenta lo contrario, considérelo como una extensión MVC (o incluso una violación). @Panzercrisis, esto difiere de MVP(como el utilizado en el Androidsistema operativo) donde actions route through the View to the Presentery el usuario tiene acceso directo a la View.
Top-Master el

455

Esto es una simplificación excesiva de las muchas variantes de estos patrones de diseño, pero así es como me gusta pensar en las diferencias entre los dos.

MVC

MVC

MVP

ingrese la descripción de la imagen aquí


10
Esta es una gran representación del esquema, que muestra la abstracción y el aislamiento completo de cualquier interfaz gráfica de usuario (ver material) de la API del presentador. Un punto menor: un presentador maestro podría usarse donde solo hay un presentador, en lugar de uno por vista, pero su diagrama es el más limpio. En mi opinión, la mayor diferencia entre MVC / MVP es que MVP trata de mantener la vista totalmente vacía de cualquier otra cosa que no sea la visualización del 'estado de vista' actual (datos de vista), mientras que también impide que la vista tenga conocimiento de los objetos del Modelo. Por lo tanto, las interfaces, que necesitan estar allí, para inyectar ese estado.

44
Buena foto. Yo uso mucho MVP, así que me gustaría hacer un punto. En mi experiencia, los presentadores necesitan hablar entre ellos con bastante frecuencia. Lo mismo es cierto para los modelos (u objetos de negocios). Debido a estas "líneas azules" adicionales de comunicación que estarían en su foto MVP, las relaciones entre el modelo y el presentador pueden enredarse bastante. Por lo tanto, tiendo a mantener una relación de Presentador-Modelo uno a uno versus uno a muchos. Sí, requiere algunos métodos delegados adicionales en el Modelo, pero reduce muchos dolores de cabeza si la API del Modelo cambia o necesita refactorización.
splungebob

3
El ejemplo de MVC está mal; Existe una estricta relación 1: 1 entre las vistas y los controladores. Por definición, un controlador interpreta la entrada de gestos humanos para producir eventos para el modelo y verlos de manera similar para un solo control. Más simplemente, MVC fue diseñado para usarse solo con widgets individuales. Un widget, una vista, un control.
Samuel A. Falvo II

3
@ SamuelA.FalvoII no siempre, hay un 1: Muchos entre controladores y vistas en ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser

44
@StuperUser: no estoy seguro de lo que estaba pensando cuando escribí eso. Tienes razón, por supuesto, y mirando hacia atrás en lo que escribí, tengo que preguntarme si tenía otro contexto en mente que no pude articular. Gracias por la corrección.
Samuel A. Falvo II

421

Hice un blog sobre esto hace un tiempo, citando la excelente publicación de Todd Snyder sobre la diferencia entre los dos :

Estas son las diferencias clave entre los patrones:

Patrón MVP

  • La vista está más unida al modelo. El presentador es responsable de vincular el modelo a la vista.
  • Prueba de unidad más fácil porque la interacción con la vista es a través de una interfaz
  • Por lo general, ver al presentador mapa uno a uno. Las vistas complejas pueden tener presentadores múltiples.

Patrón MVC

  • El controlador se basa en comportamientos y se puede compartir entre vistas
  • Puede ser responsable de determinar qué vista mostrar

Es la mejor explicación en la web que pude encontrar.


15
No entiendo cómo, en la vista, se puede acoplar más o menos de cerca al modelo cuando en ambos casos el punto completo es desacoplarlos por completo. No estoy insinuando que dijiste algo mal, solo confundido en cuanto a lo que quieres decir.
Bill K

18
@pst: con MVP es realmente 1 Vista = 1 Presentador. Con MVC, el controlador puede gobernar múltiples vistas. Eso es todo. Con el modelo de "pestañas", imagine que cada pestaña tiene su propio presentador en lugar de tener un controlador para todas las pestañas.
Jon Limjap

44
Originalmente, hay dos tipos de controladores: el que usted dijo que se compartía en varias vistas, y aquellos que son específicos de las vistas, principalmente destinados a adaptar la interfaz del controlador compartido.
Acsor

1
@JonLimjap ¿Qué significa una vista de todos modos? En el contexto de la programación de iOS, ¿es de una sola pantalla? ¿Esto hace que el controlador de iOS se parezca más a MVP que a MVC? (Por otro lado, también puede tener múltiples controladores iOS por pantalla)
huggie

2
Bueno, la ilustración esquemática de MVC de Todd contradice por completo la idea de desacoplar la Vista y el Modelo. Si observa el diagrama, dice Vista de actualizaciones del modelo (flecha de Modelo a Vista). ¿En qué universo es un sistema, donde el Modelo interactúa directamente con la Vista, uno desacoplado?
Ash

260

Aquí hay ilustraciones que representan el flujo de comunicación.

ingrese la descripción de la imagen aquí

ingrese la descripción de la imagen aquí


44
Tengo una pregunta sobre el diagrama MVC. No entiendo la parte donde la vista sale para obtener datos. Creo que el controlador reenviará la vista con los datos necesarios.
Brian Rizo

54
Si un usuario hace clic en un botón, ¿cómo es que eso no interactúa con la vista? Siento que en MVC, el usuario interactúa con la vista más que el controlador
Jonathan

55
Sé que esta es una respuesta antigua, pero ¿alguien podría responder en el punto @JonathanLeaders? Vengo de un fondo de winforms a menos que haya hecho una codificación muy única, cuando hace clic en la interfaz de usuario / Vista obtiene conocimiento de ese clic antes que cualquier otra cosa. Al menos, que yo sepa.
Rob P.

66
@RobP. Creo que este tipo de gráficos siempre tienden a ser demasiado complejos o demasiado simples. Imo, el flujo del gráfico MVP también es válido para una aplicación MVC. Puede haber variaciones, dependiendo de las características de los idiomas (enlace de datos / observador), pero al final la idea es desacoplar la vista de los datos / lógica de la aplicación.
Luca Fülbier

15
@JonathanLeaders Las personas tienen en mente cosas muy diferentes cuando dicen "MVC". La persona que creó este gráfico probablemente tenía en mente el MVC Web clásico, donde la "entrada del usuario" son solicitudes HTTP y la "vista devuelta al usuario" es una página HTML representada. Por lo tanto, cualquier interacción entre un usuario y una vista "no existe" desde la perspectiva de un autor de la aplicación clásica de Web MVC.
cubuspl42

170

MVP no es necesariamente un escenario donde la Vista está a cargo (ver MVP de Taligent, por ejemplo).
Me parece desafortunado que la gente siga predicando esto como un patrón (Vista a cargo) en lugar de un antipatrón, ya que contradice "Es solo una vista" (Programador pragmático). "Es solo una vista" indica que la vista final que se muestra al usuario es una preocupación secundaria de la aplicación. El patrón MVP de Microsoft hace que la reutilización de Vistas sea mucho más difícil y convenientemente excusa al diseñador de Microsoft de alentar las malas prácticas.

Para ser completamente franco, creo que las preocupaciones subyacentes de MVC son válidas para cualquier implementación de MVP y las diferencias son casi totalmente semánticas. Mientras esté siguiendo la separación de preocupaciones entre la vista (que muestra los datos), el controlador (que inicializa y controla la interacción del usuario) y el modelo (los datos y / o servicios subyacentes), entonces está logrando los beneficios de MVC . Si está logrando los beneficios, ¿a quién le importa realmente si su patrón es MVC, MVP o Supervising Controller? El único patrón real sigue siendo MVC, el resto son solo sabores diferentes.

Considere este artículo altamente emocionante que enumera exhaustivamente varias de estas implementaciones diferentes. Puede notar que todos están básicamente haciendo lo mismo pero de manera ligeramente diferente.

Personalmente, creo que MVP solo se ha reintroducido recientemente como un término atractivo para reducir los argumentos entre fanáticos semánticos que discuten si algo es realmente MVC o no, o para justificar las herramientas de desarrollo rápido de aplicaciones de Microsofts. Ninguna de estas razones en mis libros justifica su existencia como un patrón de diseño separado.


28
He leído varias respuestas y blogs sobre las diferencias entre MVC / MVP / MVVM / etc '. En efecto, cuando se trata de negocios, todo es lo mismo. Realmente no importa si tiene una interfaz o no, y si está utilizando un setter (o cualquier otra función de idioma). Parece que la diferencia entre estos patrones nació de la diferencia de las implementaciones de varios marcos, en lugar de una cuestión de concepto.
Michael

66
No llamaría a MVP un antipatrón , ya que más adelante en la publicación "... el resto [incluido MVP] son ​​solo diferentes sabores de [MVC] ...", lo que implicaría que si MVP fuera un antipatrón, entonces fue MVC ... es solo un sabor para el enfoque de un marco diferente. (Ahora, algunas implementaciones MVP específicas pueden ser más o menos deseables que algunas implementaciones MVC específicas para diferentes tareas ...)

@Quibblsome: “Personalmente, creo que MVP se ha reintroducido recientemente como un término pegadizo para reducir los argumentos entre fanáticos semánticos que argumentan si algo es realmente MVC o no [...] Ninguna de estas razones en mis libros justifica su existencia como un patrón de diseño separado ". . Difiere lo suficiente como para que sea distinto. En MVP, la vista puede ser cualquier cosa que cumpla con una interfaz predefinida (la Vista en MVP es un componente independiente). En MVC, el Controlador está hecho para una vista particular (si las aridades de la relación pueden hacer que alguien sienta que vale la pena otro término).
Hibou57

66
@ Hibou57, no hay nada que impida que MVC haga referencia a la vista como una interfaz o cree un controlador genérico para varias vistas diferentes.
Triste

1
Samuel, por favor aclara de qué estás hablando. A menos que me cuentes la historia del equipo que "inventó" el MVC, entonces dudo mucho de tu texto. Si solo está hablando de WinForm, existen otras formas de hacer las cosas y he creado proyectos de WinForm en los que el controlador administra los enlaces de control, no los "controles individuales".
Triste el

110

MVP: la vista está a cargo.

La vista, en la mayoría de los casos, crea su presentador. El presentador interactuará con el modelo y manipulará la vista a través de una interfaz. La vista a veces interactuará con el presentador, generalmente a través de alguna interfaz. Esto se reduce a la implementación; ¿Desea que la vista llame a métodos en el presentador o desea que la vista tenga eventos que el presentador escucha? Se reduce a esto: la vista sabe sobre el presentador. La vista delega al presentador.

MVC: el controlador está a cargo.

El controlador se crea o se accede en función de algún evento / solicitud. El controlador crea la vista adecuada e interactúa con el modelo para configurar aún más la vista. Se reduce a: el controlador crea y administra la vista; La vista es esclava del controlador. La vista no sabe sobre el controlador.


3
"La vista no sabe sobre el controlador". ¿Creo que quiere decir que esa vista no tiene contacto directo con el modelo?
Lotus Notes

2
view nunca debe saber sobre el modelo en uno.
Brian Leahy

44
@Brian: "La Vista, en la mayoría de los casos, crea su Presentador". . La mayoría de las veces vi lo contrario, con el Presentador lanzando tanto el Modelo como la Vista. Bueno, la Vista también puede lanzar el Presentador, pero ese punto no es realmente el más distintivo. Lo que más importa sucede más tarde durante la vida.
Hibou57

2
Es posible que desee editar su respuesta para explicar más: Dado que la Vista no conoce el Controlador, cómo se comunican al Controlador las acciones del usuario, que se realizan en los elementos 'visuales' que el usuario ve en la pantalla (es decir, la Vista). ...
Ash

77

ingrese la descripción de la imagen aquí

MVC (controlador de vista de modelo)

La entrada se dirige primero al controlador, no a la vista. Esa entrada podría provenir de un usuario que interactúa con una página, pero también podría ser simplemente ingresando una URL específica en un navegador. En cualquier caso, es un controlador con el que se conecta para iniciar algunas funciones. Existe una relación de muchos a uno entre el Controlador y la Vista. Esto se debe a que un solo controlador puede seleccionar diferentes vistas para representar en función de la operación que se ejecuta. Tenga en cuenta la flecha unidireccional del controlador a la vista. Esto se debe a que la Vista no tiene ningún conocimiento o referencia del controlador. El Controlador 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 (Presentador de vista de modelo)

La entrada comienza con la Vista, no con el Presentador. Hay una asignación uno a uno entre la Vista y el Presentador asociado. La vista contiene una referencia al presentador. El presentador también está reaccionando a los eventos que se activan desde la Vista, por lo que está al tanto de la Vista a la que está asociada. El presentador actualiza la vista en función de las acciones solicitadas que realiza en el modelo, pero la vista no tiene conocimiento del modelo.

Para más referencia


Pero en el MVPpatrón, cuando la aplicación se carga por primera vez, ¿no es el presentador el responsable de cargar la primera vista? Por ejemplo, cuando cargamos la aplicación de Facebook, ¿no es el presentador responsable de cargar la página de inicio de sesión?
víbora

2
¿Un enlace de Modelo a Vista en MVC? Es posible que desee editar su respuesta para explicar cómo esto lo convierte en un sistema 'desacoplado', dado este enlace. Pista: puede que te resulte difícil. Además, a menos que piense que el lector aceptará felizmente que han estado calculando mal toda su vida, es posible que desee explicar por qué las acciones pasan por el controlador primero en MVC a pesar de que el usuario interactúa con los elementos 'visuales' en la pantalla (es decir, Ver), no una capa abstracta que se encuentra detrás del procesamiento.
Ash

3
Esto está claramente mal ... en MVC, el modelo nunca habla directamente con la vista y viceversa. Ni siquiera saben que existe otro. El controlador es el pegamento que los mantiene unidos
MegaManX

1
Estoy de acuerdo con Ash y MegaManX. En el diagrama MVC, la flecha debe ser de la Vista apuntando al Modelo (o ViewModel, o DTO), no del Modelo a la Vista; porque el Modelo no conoce la Vista, pero la vista puede conocer el Modelo.
Jboy Flaga

57

Hay muchas respuestas a la pregunta, pero sentí que era necesaria una respuesta realmente simple que comparara claramente las dos. Aquí está la discusión que hice cuando un usuario busca el nombre de una película en una aplicación MVP y MVC:

Usuario: Haga clic, haga clic ...

Ver : ¿Quién es ese? [ MVP | MVC ]

Usuario: Acabo de hacer clic en el botón de búsqueda ...

Ver : Ok, espera un segundo ... [ MVP | MVC ]

( Ver llamar al presentador | Controlador ...) [ MVP | MVC ]

Ver : Hola presentador | Controlador , un usuario acaba de hacer clic en el botón de búsqueda, ¿qué debo hacer? [ MVP | MVC ]

Presentador | Controlador : Hey Vista , ¿hay algún término de búsqueda en esa página? [ MVP | MVC ]

Ver : Sí, ... aquí está ... "piano" [ 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 ]

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

Modelo : Hola presentador | Controlador , déjame comprobar ... [ MVP | MVC ]

(El modelo está haciendo una consulta a la base de datos de películas ...) [ MVP | MVC ]

( Después de un tiempo ... )

-------------- Aquí es donde MVP y MVC comienzan a divergir ---------------

Modelo : Encontré una lista para usted, Presentador , aquí está en JSON “[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993} ] ”[ 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"]. Muéstralo al usuario en una lista vertical. 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 ]

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 ...? ¿Debería estar en una lista vertical u horizontal? ...)

En caso de que le interese, he estado escribiendo una serie de artículos que tratan sobre patrones arquitectónicos de aplicaciones (MVC, MVP, MVVP, arquitectura limpia, ...) acompañados por un repositorio de Github aquí . Aunque la muestra está escrita para Android, los principios subyacentes se pueden aplicar a cualquier medio.


Básicamente, ¿lo que intenta decir es que el controlador microgestiona la lógica de la vista? ¿Entonces hace que la vista sea más tonta al presentar lo que sucede y cómo en las vistas?
Radu

@Radu, No, no hace microgestión, eso es lo que hace el presentador al hacer que la vista sea pasiva o tonta
Ali Nem

44
En un MVC adecuado, la vista invoca la funcionalidad en el controlador y escucha los cambios de datos en el modelo. La vista no obtiene datos del controlador, y el controlador NO debe decirle a la vista que muestre, por ejemplo, un indicador de carga. Un MVC adecuado le permite reemplazar la parte de vista, por una que es fundamentalmente diferente. La parte de vista tiene una lógica de vista, que incluye un indicador de carga. La vista invoca instrucciones (en el controlador), el controlador modifica los datos en el modelo y el modelo notifica a sus oyentes los cambios en sus datos, uno de esos oyentes es la vista.
Tommy Andersen

35
  • MVP = Modelo-Vista-Presentador
  • MVC = Modelo-Vista-Controlador

    1. Ambos patrones de presentación. Separan las dependencias entre un Modelo (piense en objetos de Dominio), su pantalla / página web (la Vista) y cómo se supone que debe comportarse su IU (Presentador / Controlador)
    2. Son bastante similares en concepto, la gente inicializa el presentador / controlador de manera diferente según el gusto.
    3. Un gran artículo sobre las diferencias está aquí . Lo más notable es que el patrón MVC tiene el Modelo actualizando la Vista.

2
Modelo de actualización de la vista. ¿Y esto todavía es un sistema desacoplado?
Ash

34

Modelo-Vista-Controlador

MVC es un patrón para la arquitectura de una aplicación de software. Separa la lógica de la aplicación en tres partes separadas, promoviendo la modularidad y la facilidad de colaboración y reutilización. También hace que las aplicaciones sean más flexibles y acogedoras para las iteraciones. Separa una aplicación en los siguientes componentes:

  • Modelos para el manejo de datos y lógica de negocios.
  • Controladores para manejar la interfaz de usuario y la aplicación
  • Vistas para manejar objetos de interfaz gráfica de usuario y presentación

Para aclarar esto un poco, imaginemos una aplicación simple de lista de compras. Todo lo que queremos es una lista del nombre, la cantidad y el precio de cada artículo que necesitamos comprar esta semana. A continuación, describiremos cómo podríamos implementar parte de esta funcionalidad utilizando MVC.

ingrese la descripción de la imagen aquí

Modelo-Vista-Presentador

  • El modelo son los datos que se mostrarán en la vista (interfaz de usuario).
  • La vista es una interfaz que muestra datos (el modelo) y enruta los comandos del usuario (eventos) al Presentador para actuar sobre esos datos. La vista generalmente tiene una referencia a su presentador.
  • El presentador es el "intermediario" (interpretado por el controlador en MVC) y tiene referencias tanto a la vista como al modelo. Tenga en cuenta que la palabra "Modelo" es engañosa. Más bien debería ser la lógica de negocios que recupera o manipula un modelo . Por ejemplo: si tiene una base de datos que almacena al Usuario en una tabla de base de datos y su Vista desea mostrar una lista de usuarios, el Presentador tendrá una referencia a la lógica de negocios de su base de datos (como un DAO) desde donde el Presentador consultará una lista de usuarios.

Si desea ver una muestra con una implementación simple, consulte esta publicación de GitHub

Un flujo de trabajo concreto de consultas y visualización de una lista de usuarios de una base de datos podría funcionar así: ingrese la descripción de la imagen aquí

¿Cuál es la diferencia entre los patrones MVC y MVP ?

Patrón MVC

  • El controlador se basa en comportamientos y se puede compartir entre vistas

  • Puede ser responsable de determinar qué vista mostrar (Patrón del controlador frontal)

Patrón MVP

  • La vista está más unida al modelo. El presentador es responsable de vincular el modelo a la vista.

  • Prueba de unidad más fácil porque la interacción con la vista es a través de una interfaz

  • Por lo general, ver al presentador mapa uno a uno. Las vistas complejas pueden tener presentadores múltiples.


2
no, no hay conexión directa entre la vista y el modelo en mvc. Tu diagrama está mal.
Özgür

33

También vale la pena recordar que también hay diferentes tipos de MVP. Fowler ha dividido el patrón en dos: vista pasiva y controlador de supervisión.

Al usar la Vista pasiva, su Vista generalmente implementa una interfaz de grano fino con propiedades que se asignan más o menos directamente al widget de interfaz de usuario subyacente. Por ejemplo, puede tener un ICustomerView con propiedades como Nombre y Dirección.

Su implementación podría verse así:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Su clase de presentador hablará con el modelo y lo "asignará" a la vista. Este enfoque se denomina "Vista pasiva". El beneficio es que la vista es fácil de probar y es más fácil moverse entre plataformas de IU (Web, Windows / XAML, etc.). La desventaja es que no puede aprovechar cosas como el enlace de datos (que es realmente poderoso en marcos como WPF y Silverlight ).

El segundo sabor de MVP es el controlador de supervisión. En ese caso, su Vista podría tener una propiedad llamada Cliente, que nuevamente está vinculada a los widgets de la IU. No tiene que pensar en la sincronización y la microgestión de la vista, y el Supervisor Controller puede intervenir y ayudar cuando sea necesario, por ejemplo, con una lógica de interacción completa.

El tercer "sabor" de MVP (o alguien quizás lo llamaría un patrón separado) es el Modelo de Presentación (o a veces referido a Model-View-ViewModel). En comparación con el MVP, "fusionas" la M y la P en una sola clase. Tiene su objeto de cliente al que sus widgets de IU están vinculados a datos, pero también tiene campos específicos de IU adicionales como "IsButtonEnabled" o "IsReadOnly", etc.

Creo que el mejor recurso que he encontrado para la arquitectura de la interfaz de usuario es la serie de publicaciones de blog realizadas por Jeremy Miller en la tabla de contenido de la serie Build Your Own CAB . Cubrió todos los sabores de MVP y mostró el código C # para implementarlos.

También he blogueado sobre el patrón Model-View-ViewModel en el contexto de Silverlight en YouCard Re-visit: Implementando el patrón ViewModel .


25

Cada uno aborda diferentes problemas e incluso se pueden combinar para tener algo como a continuación

El patrón combinado

También hay una comparación completa de MVC, MVP y MVVM aquí


1
En lugar de complicar demasiado las cosas, podrías haber respondido la pregunta. Es por eso que la mayoría de nosotros estamos aquí. Busqué la comparación entre mvp y mvc y me redirigieron aquí y estás hablando de la armonía de esas arquitecturas que no está relacionada con OP.
Farid

18

Ambos marcos tienen como objetivo separar las preocupaciones, por ejemplo, la interacción con una fuente de datos (modelo), la lógica de la aplicación (o convertir estos datos en información útil) (Controlador / Presentador) y mostrar el código (Ver). En algunos casos, el modelo también se puede utilizar para convertir una fuente de datos en una abstracción de nivel superior. Un buen ejemplo de esto es el proyecto MVC Storefront .

Hay una discusión aquí con respecto a las diferencias entre MVC vs MVP.

La distinción que se hace es que en una aplicación MVC tradicionalmente la vista y el controlador interactúan con el modelo, pero no entre sí.

Los diseños de MVP hacen que el presentador acceda al modelo e interactúe con la vista.

Dicho esto, ASP.NET MVC es, según estas definiciones, un marco MVP porque el Controlador accede al Modelo para llenar la Vista que no tiene lógica (solo muestra las variables proporcionadas por el Controlador).

Para tener una idea de la distinción ASP.NET MVC de MVP, consulte esta presentación MIX de Scott Hanselman.


77
MVC y MVP son patrones, no marcos. Si honestamente piensas, ese tema era sobre .NET Framework, entonces es como escuchar "internet" y pensar que se trata de IE.
tereško

Estoy bastante seguro de que la pregunta ha evolucionado significativamente desde que se hizo por primera vez en 2008. Además, mirando hacia atrás a mi respuesta (y esto fue hace 4 años, así que no tengo mucho más contexto que tú), diría que empiezo en general y luego use .NET MVC como ejemplo concreto.
Matt Mitchell

13

Ambos son patrones que intentan separar la presentación y la lógica empresarial, desacoplando la lógica empresarial de los aspectos de la interfaz de usuario

Arquitectónicamente, MVP es un enfoque basado en el controlador de página donde MVC es un enfoque basado en el controlador frontal. Eso significa que en el ciclo de vida de la página web estándar de MVP solo se mejora al extraer la lógica empresarial del código subyacente. En otras palabras, la página es la que atiende la solicitud http. En otras palabras, MVP IMHO es un tipo de mejora evolutiva de forma web. MVC, por otro lado, cambia completamente el juego porque la solicitud es interceptada por la clase de controlador antes de que se cargue la página, la lógica de negocios se ejecuta allí y luego, al final del resultado, el controlador procesa los datos que se descargan en la página ("vista"). sentido, MVC se parece (al menos a mí) mucho al sabor del controlador supervisor de MVP mejorado con el motor de enrutamiento

Ambos habilitan TDD y tienen desventajas y desventajas.

La decisión sobre cómo elegir uno de ellos en mi humilde opinión debería basarse en la cantidad de tiempo que uno invirtió en el tipo de desarrollo web de formulario web ASP NET. Si uno se considerara bueno en los formularios web, sugeriría MVP. Si uno no se sintiera tan cómodo en cosas como el ciclo de vida de la página, etc. MVC podría ser una manera de hacerlo aquí.

Aquí hay otro enlace de publicación de blog que brinda un poco más de detalles sobre este tema

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx


9

He usado MVP y MVC y aunque nosotros, como desarrolladores, tendemos a centrarnos en las diferencias técnicas de ambos patrones, el punto para MVP en mi humilde opinión está mucho más relacionado con la facilidad de adopción que con cualquier otra cosa.

Si estoy trabajando en un equipo que ya tiene una buena experiencia en el estilo de desarrollo de formularios web, es mucho más fácil presentar MVP que MVC. Yo diría que MVP en este escenario es una victoria rápida.

Mi experiencia me dice que mover un equipo de formularios web a MVP y luego de MVP a MVC es relativamente fácil; pasar de formularios web a MVC es más difícil.

Dejo aquí un enlace a una serie de artículos que un amigo mío ha publicado sobre MVP y MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx


8

En MVP, la vista extrae datos del presentador, que extrae y prepara / normaliza datos del modelo, mientras que en MVC el controlador extrae datos del modelo y el conjunto presionando la vista.

En MVP, puede tener una única vista trabajando con múltiples tipos de presentadores y un solo presentador trabajando con diferentes vistas múltiples.

MVP generalmente usa algún tipo de marco de enlace, como el marco de enlace de Microsoft WPF o varios marcos de enlace para HTML5 y Java.

En esos marcos, la interfaz de usuario / HTML5 / XAML es consciente de qué propiedad del presentador muestra cada elemento de la interfaz de usuario, por lo que cuando vincula una vista a un presentador, la vista busca las propiedades y sabe cómo extraer datos de ellas y cómo para establecerlos cuando el usuario cambia un valor en la interfaz de usuario.

Entonces, si, por ejemplo, el modelo es un automóvil, entonces el presentador es una especie de presentador de automóviles, expone las propiedades del automóvil (año, fabricante, asientos, etc.) a la vista. La vista sabe que el campo de texto llamado 'fabricante de automóviles' debe mostrar la propiedad Maker del presentador.

A continuación, puede vincular a la vista muchos tipos diferentes de presentador, todos deben tener la propiedad Maker: puede ser de un avión, un tren o lo que sea, a la vista no le importa. La vista extrae datos del presentador, sin importar cuál, siempre que implemente una interfaz acordada.

Este marco vinculante, si lo quitas, en realidad es el controlador :-)

Y así, puedes ver MVP como una evolución de MVC.

MVC es genial, pero el problema es que generalmente su controlador por vista. El Controlador A sabe cómo configurar los campos de la Vista A. Si ahora desea que la Vista A muestre datos del modelo B, necesita el Controlador A para conocer el modelo B, o necesita el Controlador A para recibir un objeto con una interfaz, que es como MVP solo sin los enlaces, o necesita reescribir el código de configuración de la interfaz de usuario en el controlador B.

Conclusión: MVP y MVC son ambos desacoplamiento de patrones de IU, pero MVP generalmente usa un marco de enlaces que es MVC debajo. THUS MVP está en un nivel arquitectónico más alto que MVC y un patrón de envoltura por encima de MVC.


6

Mi humilde visión corta: MVP es para escalas grandes y MVC para escalas pequeñas. Con MVC, en algún momento siento que la V y la C pueden verse a dos lados de un solo componente indivisible en lugar de estar directamente unido a M, y uno inevitablemente cae en esto cuando baja a escalas más cortas, como controles de UI y widgets de base. En este nivel de granularidad, MVP tiene poco sentido. Cuando uno por el contrario va a escalas más grandes, la interfaz adecuada se vuelve más importante, lo mismo con la asignación inequívoca de responsabilidades, y aquí viene MVP.

Por otro lado, esta regla general de escala puede pesar muy poco cuando las características de la plataforma favorecen algún tipo de relación entre los componentes, como con la web, donde parece ser más fácil implementar MVC, más que MVP.


4

Creo que esta imagen de Erwin Vandervalk (y el artículo adjunto ) es la mejor explicación de MVC, MVP y MVVM, sus similitudes y sus diferencias. El artículo no aparece en los resultados del motor de búsqueda para consultas sobre "MVC, MVP y MVVM" porque el título del artículo no contiene las palabras "MVC" y "MVP"; pero es la mejor explicación, creo.

imagen explicando MVC, MVP y MVVM - por Erwin Vandervalk

(El artículo también coincide con lo que dijo el tío Bob Martin en una de sus charlas: que MVC fue diseñado originalmente para los pequeños componentes de la interfaz de usuario, no para la arquitectura del sistema)


3

Hay muchas versiones de MVC, esta respuesta es sobre el MVC original en Smalltalk. En resumen, es imagen de mvc vs mvp

Esta charla droidcon NYC 2017: el diseño limpio de la aplicación con componentes de arquitectura lo aclara

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí


66
En el MVC, el modelo nunca se llama directamente desde la vista
rodi

55
Esta es una respuesta inexacta. No te dejes engañar. Como escribe @rodi, no hay interacción entre la Vista y el Modelo.
Shawn Mehan

La imagen MVC es inexacta o, en el mejor de los casos, engañosa, no preste atención a esta respuesta.
Jay

2
@ Jay1b ¿Qué MVC crees que es "correcto"? Esta respuesta es sobre el MVC original. Hay muchos otros MVC (como en iOS) que se cambiaron para adaptarse a la plataforma, digamos comoUIKit
onmyway133

¿Qué significan las flechas?
problemofficer

3

No es este bonito vídeo del Tío Bob donde explica brevemente MVC y MVP al final.

En mi opinión, MVP es una versión mejorada de MVC donde básicamente separas la preocupación de lo que mostrarás (los datos) de cómo mostrarás (la vista). El presentador incluye un poco la lógica empresarial de su interfaz de usuario, impone implícitamente qué datos deben presentarse y le brinda una lista de modelos de vista tontos. Y cuando llegue el momento de mostrar los datos, simplemente conecte su vista (probablemente incluya la misma identificación) en su adaptador y configure los campos de vista relevantes usando esos modelos de vista con una cantidad mínima de código que se introduce (solo usando los configuradores). Su principal beneficio es que puede probar su lógica de negocio de interfaz de usuario contra muchas / diversas vistas, como mostrar elementos en una lista horizontal o vertical.

En MVC, hablamos a través de interfaces (límites) para pegar diferentes capas. Un controlador es un complemento de nuestra arquitectura, pero no tiene esa restricción para imponer qué mostrar. En ese sentido, MVP es una especie de MVC con un concepto de vistas que se pueden conectar al controlador a través de adaptadores.

Espero que esto ayude mejor.


2
Punto importante del tío Bob: cuando originalmente fue inventado por Trygve Reenskaug, MVC estaba destinado a cada widget, no a todo el formulario.
Basil Bourque

2

Se olvidó de Action-Domain-Responder ( ADR ).

Como se explica en algunos gráficos anteriores, hay una relación / vínculo directo entre el Modelo y la Vista en MVC. Se realiza una acción en el Controlador , que ejecutará una acción en el Modelo . Esa acción en el Modelo , desencadenará una reacción en la Vista . La Vista , siempre se actualiza cuando cambia el estado del Modelo .

Algunas personas se olvidan de que MVC se creó a finales de los 70 " y que la Web solo se creó a fines de los 80" / principios de los 90 ". MVC no se creó originalmente para la Web, sino para aplicaciones de escritorio, donde el controlador , Modelo y Vista coexistirían juntos.

Debido a que usamos frameworks web ( por ejemplo: Laravel ) que todavía usan las mismas convenciones de nomenclatura ( model-view-controller ), tendemos a pensar que debe ser MVC, pero en realidad es otra cosa.

En cambio, eche un vistazo a Action-Domain-Responder . En ADR, el Controlador obtiene una Acción , que realizará una operación en el Modelo / Dominio . Hasta ahora, lo mismo. La diferencia es que luego recolecta la respuesta / datos de esa operación y la pasa a un Respondedor ( por ejemplo:)view() para su representación. Cuando se solicita una nueva acción en el mismo componente, se llama nuevamente al controlador y el ciclo se repite. En ADR, no hay conexión entre el Modelo / Dominio y la Vista ( respuesta del respondedor ).

Nota: Wikipedia establece que " Cada acción de ADR, sin embargo, está representada por clases o cierres separados ". Esto no es necesariamente cierto. Varias acciones pueden estar en el mismo controlador, y el patrón sigue siendo el mismo.


2

La respuesta más simple es cómo interactúa la vista con el modelo. En MVP, el presentador actualiza la vista, que actúa como intermediario entre la vista y el modelo. El presentador toma la entrada de la vista, que recupera los datos del modelo y luego realiza cualquier lógica de negocios requerida y luego actualiza la vista. En MVC, el modelo actualiza la vista directamente en lugar de volver a través del controlador.


He votado en contra, porque afaik el modelo no sabe nada sobre la vista en MVC y no puede actualizarlo directamente mientras escribe.
problemofficer

1
Mire MVC en Wikipedia, así es exactamente como funciona.
Clive Jefferies

1
Ya sea que a los lectores les guste o no, muchas fuentes que se pueden encontrar buscando en Google afirman que en MVC la vista se suscribe a las actualizaciones del modelo. y en algunos casos incluso podría ser el controlador y, por lo tanto, invocar tales actualizaciones. Si no le gusta eso, vaya a quejarse de esos artículos, o cite qué 'biblia' cree que es la única fuente legítima, en lugar de rechazar las respuestas que solo transmiten la otra información disponible.
underscore_d

1
La redacción definitivamente podría mejorarse, pero es cierto que la vista se suscribe a los cambios en el modelo en MVC. El modelo no necesita conocer la Vista en MVC.
Devorado elysium el

gracias ... Me ayudó mucho
Dvyn Resh

1
  • En MVC, View tiene la parte de UI, el controlador es el mediador entre view y model & model contiene la lógica de negocios.
  • En MVP, View contiene tanto la interfaz de usuario como la implementación del presentador, ya que aquí el presentador es solo una interfaz y el modelo es el mismo, es decir, contiene lógica de negocios.

-1

MVP

MVP significa Modelo - Vista - Presentador. Esto llegó a una imagen a principios de 2007 donde Microsoft introdujo las aplicaciones de Windows Smart Client.

Un presentador actúa como una función de supervisión en MVP que vincula los eventos de visualización y la lógica empresarial de los modelos.

El enlace de evento de vista se implementará en el Presentador desde una interfaz de vista.

La vista es el iniciador de las entradas del usuario y luego delega los eventos al presentador y el presentador maneja los enlaces de eventos y obtiene datos de los modelos.

Pros: La vista solo tiene IU, no ninguna lógica. Alto nivel de comprobabilidad.

Contras: poco complejo y más trabajo al implementar enlaces de eventos

MVC

MVC significa Modelo-Vista-Controlador. El controlador es responsable de crear modelos y representar vistas con modelos vinculantes.

El controlador es el iniciador y decide qué vista representar.

Pros: Énfasis en el principio de responsabilidad única. Alto nivel de comprobabilidad.

Contras: a veces demasiada carga de trabajo para los Controladores, si intenta renderizar múltiples vistas en el mismo controlador.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.