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

StackOverflow https://stackoverflow.com/questions/2056

Pregunta

Al mirar más allá del RAD (arrastrar, soltar y configurar) de crear interfaces de usuario que muchas herramientas recomiendan, es probable que se encuentre con tres patrones de diseño llamados Modelo-Vista-Controlador, Modelo-Vista-Presentador y Modelo-Vista-VerModelo.Mi pregunta tiene tres partes:

  1. ¿Qué cuestiones abordan estos patrones?
  2. ¿En qué se parecen?
  3. ¿En qué se diferencian?
¿Fue útil?

Solución

Modelo-Vista-Presentador

En MVP, el Presentador contiene la lógica empresarial de la interfaz de usuario para la Vista.Todas las invocaciones desde la Vista se delegan directamente al Presentador.El Presentador también está desacoplado directamente de la Vista y le habla a través de una interfaz.Esto es para permitir burlarse de la Vista en una prueba unitaria.Un atributo común de MVP es que tiene que haber mucho envío bidireccional.Por ejemplo, cuando alguien hace clic en el botón "Guardar", el controlador de eventos delega en el 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 una presentación separada en formularios web.La razón es que la Vista siempre la crea primero el tiempo de ejecución de ASP.NET.Puede Obtenga 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 entre sí.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 definidor que el Presentador utiliza para configurar los datos.Todo el estado se gestiona en el Presentador y no en la Vista.

  • Pro:superficie máxima de comprobabilidad;separación limpia de la Vista y el Modelo
  • Estafa:más trabajo (por ejemplo, todas las propiedades del definidor) ya que usted mismo realiza todos los enlaces de datos.

Controlador supervisor: El presentador maneja los gestos del usuario.La Vista se vincula al Modelo directamente mediante el enlace de datos.En este caso, es 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.
  • Estafa: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 dirigen 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 al otro lado de la cual hay un Controlador que responde.Una vez que ese Controlador haya completado su procesamiento, devolverá la Vista correcta.La secuencia continúa de esa manera durante toda la vida de la aplicación:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

Otra gran diferencia sobre MVC es que la Vista no se vincula directamente al Modelo.La vista simplemente se representa y no tiene ningún estado.En las implementaciones de MVC, la Vista generalmente no tendrá ninguna lógica en el código subyacente.Esto es contrario a MVP, donde es absolutamente necesario porque, si la Vista no delega al Presentador, nunca será llamada.

Modelo de presentación

Otro patrón a observar es el Modelo de presentación patrón.En este patrón no hay presentador.En cambio, la Vista se vincula 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 incluirí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 vincula al modelo de dominio y puede suscribirse a eventos provenientes de ese modelo.Luego, la Vista se suscribe a los eventos provenientes del Modelo de presentación y se actualiza en consecuencia.El modelo de presentación puede exponer comandos que la vista utiliza 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.Este patrón es un candidato muy fuerte para su uso en aplicaciones WPF y también se llama Modelo-Vista-VerModelo.

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

Otros consejos

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

mvc

MVC

MVP

enter image description here

Escribí un blog sobre esto hace un tiempo, citando 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 vagamente acoplada al modelo.El presentador es responsable de vincular el modelo a la vista.
  • Más fácil de probar unir porque la interacción con la vista es a través de una interfaz
  • Por lo general, ve el mapa del presentador uno a uno.Las vistas complejas pueden tener múltiples presentadores.

Patrón MVC

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

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

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

enter image description here

enter image description here

MVP es no necesariamente un escenario donde la Vista está a cargo (ver el 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 sólo 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 fomentar malas prácticas.

Para ser completamente sincero, creo que las preocupaciones subyacentes de MVC son válidas para cualquier implementación de MVP y las diferencias son casi completamente semánticas.Siempre que siga 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 estará 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 real El patrón permanece como MVC, el resto son solo versiones diferentes del mismo.

Considerar este Artículo muy interesante que enumera exhaustivamente varias de estas diferentes implementaciones.Puede notar que básicamente todos hacen lo mismo pero de manera ligeramente diferente.

Personalmente, creo que MVP se ha reintroducido recientemente como un término atractivo para reducir las discusiones 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 Microsoft.Ninguna de estas razones en mis libros justifica su existencia como un patrón de diseño separado.

Jugador Más Valioso: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.En ocasiones, la vista interactuará con el presentador, generalmente a través de alguna interfaz.Esto se reduce a la implementación;¿Quiere que la vista llame a métodos en el presentador o quiere que la vista tenga eventos que el presentador escuche?Todo 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 a él en función de algún evento/solicitud.Luego, 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 gestiona la vista;la vista es esclava del controlador.La vista no sabe nada del controlador.

enter image description here

MVC (controlador de vista de modelo)

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 puede provenir simplemente de ingresar una URL específica en un navegador.En cualquier caso, es un controlador con el que se interconecta para iniciar alguna funcionalidad.Existe una relación de muchos a uno entre el Controlador y la Vista.Esto se debe a que un único controlador puede seleccionar diferentes vistas para renderizar según la operación que se esté ejecutando.Tenga en cuenta la flecha unidireccional del Controlador a la Vista.Esto se debe a que la Vista no tiene ningún conocimiento ni referencia al 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 entrega.

MVP (presentador de vista de modelo)

La entrada comienza con la Vista, no con el Presentador.Existe una asignación uno a uno entre la Vista y el Presentador asociado.La Vista tiene una referencia al Presentador.El Presentador también reacciona a los eventos que se activan desde la Vista, por lo que conoce la Vista a la que está asociado.El Presentador actualiza la Vista en función de las acciones solicitadas que realiza en el Modelo, pero la Vista no reconoce el Modelo.

Para más Referencia

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

Usuario:Clic clic …

Vista:¿Quién es ese?[MVP|mvc]

Usuario:Acabo de hacer clic en el botón de buscar...

Vista:Ok, espera un segundo….[MVP|mvc]

( Vista llamando al Presentador|Controlador … ) [MVP|mvc]

Vista:Ey Presentador|Controlador, un Usuario acaba de hacer clic en el botón buscar, ¿qué debo hacer?[MVP|mvc]

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

Vista:Sí,… aquí está… “piano” [MVP|mvc]

Presentador:Gracias Vista,… mientras tanto busco el término de búsqueda en el Modelo, por favor muéstrale una barra de progreso [MVP|mvc]

( Presentador|Controlador está llamando al Modelo … ) [MVP|mvc]

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

Modelo:Ey Presentador|Controlador, permítame verificar … [MVP|mvc]

( Modelo está haciendo una consulta a la base de datos de películas…) [MVP|mvc]

( Al poco tiempo ...)

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

Modelo:Encontré una lista para ti Presentador, aquí está en JSON “[{"name":"Piano Teacher","year":2001},{"name":"Piano","year":1993}]” [MVP]

Modelo:Hay algún resultado disponible, Controlador.Creé una variable de campo en mi instancia y la llené con el resultado.Su nombre es "searchResultsList" [mvc]

(Presentador|Controlador gracias Modelo y vuelve a la Vista) [MVP|mvc]

Presentador:Gracias por esperar Vista, encontré una lista de resultados coincidentes para usted y los ordené en un formato presentable:["Profesor de piano 2001","Piano 1993"].Muéstrelo al usuario en una lista vertical.También oculte la barra de progreso ahora [MVP]

Controlador:Gracias por esperar Vista, He preguntado Modelo sobre su consulta de búsqueda.Dice que encontró una lista de resultados coincidentes y los almacenó en una variable llamada "searchResultsList" dentro de su instancia.Puedes conseguirlo desde allí.También oculte la barra de progreso ahora [mvc]

Vista:Muchas gracias Presentador [MVP]

Vista:Gracias "Controlador" [mvc] (Ahora el Vista se cuestiona a sí mismo:¿Cómo debo presentar los resultados que obtengo del Modelo al usuario?¿El año de producción de la película debería ser el primero o el último...?¿Debería estar en una lista vertical u horizontal?...)

En caso de que esté interesado, he estado escribiendo una serie de artículos que tratan sobre patrones arquitectónicos de aplicaciones (MVC, MVP, MVVP, arquitectura limpia,...) acompañados de un repositorio de Github. aquí.Aunque el ejemplo está escrito 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 los objetos de Dominio), su pantalla/página web (la Vista) y cómo se supone que debe comportarse su UI (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 es aquí.Lo más notable es que el patrón MVC hace que el modelo actualice la vista.

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

Cuando se utiliza la Vista pasiva, su Vista generalmente implementa una interfaz detallada con propiedades que se asignan más o menos directamente al widget de interfaz de usuario subyacente.Por ejemplo, es posible que tenga 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 Presentador hablará con el modelo y lo "mapeará" 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 interfaz de usuario (Web, Windows/XAML, etc.).La desventaja es que no puedes aprovechar cosas como el enlace de datos (que es en realidad potente en marcos como WPF y Luz plateada).

La segunda versión de MVP es el controlador supervisor.En ese caso, su Vista podría tener una propiedad llamada Cliente, que nuevamente está vinculada a los datos de los widgets de la interfaz de usuario.No tiene que pensar en sincronizar y microadministrar la vista, y el controlador supervisor 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 denominado Modelo-Vista-Modelo de Vista).En comparación con el MVP, "fusionas" la M y la P en una sola clase.Tiene su objeto de cliente al que están vinculados los datos de sus widgets de interfaz de usuario, pero también tiene campos adicionales específicos de la interfaz de usuario 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 Índice de la serie Construya su propio CAB.Cubrió todos los tipos de MVP y mostró código C# para implementarlos.

También escribí en un blog sobre el patrón Model-View-ViewModel en el contexto de Silverlight en YouCard revisitada:Implementando el patrón ViewModel.

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 manejar datos y lógica de negocios
  • Controladores para manejar la interfaz de usuario y la aplicación
  • Puntos de vista para manejar objetos y presentaciones de la interfaz gráfica de usuario

Para que esto quede un poco más claro, imaginemos una sencilla aplicación de lista de compras.Todo lo que queremos es una lista del nombre, cantidad y precio de cada artículo que necesitamos comprar esta semana.A continuación describiremos cómo podríamos implementar algunas de estas funciones usando MVC.

enter image description here

Modelo-Vista-Presentador

  • El modelo son los datos que se mostrarán en la vista (interfaz de usuario).
  • El vista es una interfaz que muestra datos (el modelo) y enruta comandos del usuario (eventos) al Presentador para actuar sobre esos datos.La vista suele tener 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 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, entonces el Presentador tendría 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 un ejemplo con una implementación sencilla, consulte este publicación de github

Un flujo de trabajo concreto para consultar y mostrar una lista de usuarios de una base de datos podría funcionar así:enter image description here

Cuál es el diferencia entre mvc y MVP ¿patrones?

Patrón MVC

  • Los controladores se basan en comportamientos y se pueden compartir entre vistas

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

Patrón MVP

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

  • Es más fácil realizar pruebas unitarias porque la interacción con la vista se realiza a través de una interfaz.

  • Por lo general, ve el mapa del presentador uno a uno.Las vistas complejas pueden tener varios presentadores.

Cada uno de ellos aborda diferentes problemas e incluso se pueden combinar para tener algo como lo siguiente

The Combined Pattern

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

Ambos marcos tienen como objetivo separar 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 código de visualización (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 de escaparate MVC.

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 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 completar la Vista, que no debe tener lógica (solo muestra las variables proporcionadas por el Controlador).

Quizás para tener una idea de la distinción entre ASP.NET MVC y MVP, consulte esta presentación MIX por Scott Hanselman.

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

Desde el punto de vista arquitectónico, MVP es un enfoque basado en el controlador de página, mientras que MVC es un enfoque basado en el controlador frontal.Eso significa que en el formulario web estándar MVP, el ciclo de vida de la página simplemente 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 en mi humilde opinión es un tipo de mejora evolutiva en forma web.MVC, por otro lado, cambia por completo el juego porque la solicitud se intercepta por la clase del controlador antes de que se cargue la página, la lógica comercial se ejecuta allí y luego al final del controlador procesa los datos que se acaban de ver a la página ("Ver") en eso Sense, MVC se ve (al menos para mí) mucho a supervisar el sabor del controlador de MVP mejorado con el motor de enrutamiento

Ambos permiten TDD y tienen ventajas y desventajas.

La decisión sobre cómo elegir uno de ellos en mi humilde opinión debe basarse en cuánto tiempo se invierte en el tipo de desarrollo web ASP NET.Si uno se considera bueno en formularios web, sugeriría MVP.Si uno no se siente tan cómodo con cosas como el ciclo de vida de la página, etc., MVC podría ser un camino a seguir 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 tanto MVP como 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 cualquier otra cosa.

Si trabajo 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 los configura presionando la vista.

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

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

En esos marcos, UI/HTML5/XAML sabe 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 configurarlos 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óvil y 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 Fabricante del presentador.

Luego puede vincular a la vista muchos tipos diferentes de presentadores, todos deben tener propiedad Maker: puede ser 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 eliminas, en realidad es el controlador :-)

Entonces, puedes considerar MVP como una evolución de MVC.

MVC es genial, pero el problema es que normalmente 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 que el Controlador A conozca el modelo B, o necesita que el Controlador A reciba un objeto con una interfaz, que es como MVP solo que sin los enlaces, o necesita reescribir el código de configuración de UI en el Controlador B.

Conclusión: MVP y MVC están desacoplados de patrones de interfaz de usuario, pero MVP generalmente usa un marco de enlaces que es MVC debajo.POR LO TANTO, MVP está en un nivel arquitectónico más alto que MVC y un patrón contenedor por encima de MVC.

Mi humilde y breve visión:MVP es para escalas grandes y MVC para escalas pequeñas.Con MVC, a veces siento que la V y la C pueden verse como dos lados de un único componente indivisible, más bien directamente vinculado a M, y uno inevitablemente cae en esto cuando se baja a escalas más cortas, como controles de UI y widgets base.En este nivel de granularidad, MVP tiene poco sentido.Por el contrario, cuando uno va a escalas mayores, la interfaz adecuada se vuelve más importante, lo mismo ocurre 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 ocurre con la web, donde parece más fácil implementar MVC que MVP.

Hay este Buen video del tío Bob donde explica brevemente MVC y MVP al final.

En mi opinión, MVP es una versión mejorada de MVC en la que básicamente separas la preocupación de lo que vas a mostrar (los datos) de cómo vas a mostrar (la vista).Presenter 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 las mismas identificaciones) en su adaptador y configure los campos de vista relevantes usando esos modelos de vista con una cantidad mínima de código introducido (solo usando configuradores).Su principal beneficio es que puede probar la lógica empresarial de su interfaz de usuario con muchas o varias vistas, como mostrar elementos en una lista horizontal o vertical.

En MVC, hablamos a través de interfaces (límites) para unir diferentes capas.El controlador es un complemento de nuestra arquitectura, pero no tiene tal 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.

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

esta charla droidcon NYC 2017: diseño limpio de aplicaciones con componentes de arquitectura lo aclara

enter image description here enter image description here

La respuesta más sencilla es cómo interactúa la vista con el modelo.En MVP, la vista está vinculada al presentador, que actúa como intermediario entre la vista y el modelo, tomando información de la vista, obteniendo datos del modelo, luego realizando una lógica de negocios y finalmente actualizando la vista.En MVC, el modelo actualiza la vista directamente en lugar de volver a través del controlador.

Creo que esta imagen de Erwin Vandervalk (y la que la acompaña artículo) es la mejor explicación de MVC, MVP y MVVM, sus similitudes y 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 creo que es la mejor explicación.

image explaining MVC, MVP and MVVM - by 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)

MVP

MVP significa Modelo - Vista - Presentador.Esto surgió a principios de 2007, cuando Microsoft introdujo las aplicaciones de Windows Smart Client.

El 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 eventos de vista se implementará en Presenter desde una interfaz de vista.

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

Ventajas:La vista es solo que la interfaz de usuario no es una lógica un alto nivel de prueba

Contras:Un 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.

Ventajas:Énfasis en el principio de responsabilidad individual alto nivel de prueba

Contras:A veces, hay demasiada carga de trabajo para los controladores si se intenta representar varias vistas en el mismo controlador.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top