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

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?

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

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

MVP

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.

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

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.

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.

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

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.

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

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.

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í:

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

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 .

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

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

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.

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

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

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.

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.

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.

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

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

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

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.

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.

mvc adr modelo-vista-controlador respondedor de dominio de acción

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.

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

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.