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

votos
1k

Al mirar más allá de la forma RAD (arrastrar y soltar) de crear interfaces de usuario que muchas herramientas le alientan es probable que encuentre 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. ¿Cómo son similares?
  3. ¿En qué se diferencian?
Publicado el 05/08/2008 a las 11:06
fuente por usuario
En otros idiomas...                            


25 respuestas

votos
1k

Modelo-Vista-Presentador

En MVP , el presentador contiene la lógica de negocios de la interfaz de usuario para la vista. Todas las invocaciones de View delegan directamente a Presenter. El presentador también está desacoplado directamente de la vista y habla con él 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 un gran despacho 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 se ha completado el guardado.

MVP tiende a ser un patrón muy natural para lograr una presentación separada en Web Forms. La razón es que la Vista siempre se crea primero por el tiempo de ejecución de ASP.NET. Puede encontrar más información sobre ambas variantes .

Dos variaciones principales

Vista pasiva: la vista es tan estúpida como sea 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 colocador que el presentador usa para establecer los datos. Todo el estado se gestiona en el presentador y no en la vista.

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

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

  • Pro: al aprovechar la unión de datos, se reduce la cantidad de código.
  • Con: hay menos superficie comprobable (debido a la vinculación 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 del 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 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 durante toda la vida de la aplicación:

    Acción en la vista
        -> Llamada al controlador
        -> Controlador Lógico
        -> El controlador devuelve la Vista.

Otra gran diferencia sobre MVC es que la Vista no se vincula directamente al Modelo. La vista simplemente se renderiza, y es completamente sin estado. En las implementaciones de MVC, la vista generalmente no tendrá lógica en el código. Esto es contrario a MVP, donde es absolutamente necesario porque, si la vista no se delega en el presentador, nunca se llamará.

Modelo de presentación

Otro patrón para mirar es el modelo de presentaciónpatrón. 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 vincula al modelo de dominio y puede suscribirse a eventos provenientes de ese modelo. 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 básicamente puede eliminar el código subyacente ya que el PM encapsula completamente todo el comportamiento de la vista.Model-View-ViewModel .

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 (Prism anterior) sobre Patrones de Presentación Separados.

Respondida el 19/09/2008 a las 13:46
fuente por usuario

votos
381

Publiqué un blog sobre esto hace un tiempo, citando el excelente artículo de Todd Snyder sobre la diferencia entre los dos :

Estas son las diferencias clave entre los patrones:

Patrón de MVP

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

Patrón MVC

  • Controlador se basan en comportamientos y se pueden compartir a través de vistas
  • Puede ser responsable de determinar qué vista mostrar

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

Respondida el 05/08/2008 a las 11:21
fuente por usuario

votos
358

Esta es una simplificación 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

introducir descripción de la imagen aquí

Respondida el 06/07/2013 a las 23:18
fuente por usuario

votos
202

Aquí son ilustraciones que representan el flujo de comunicación

introducir descripción de la imagen aquí

introducir descripción de la imagen aquí

Respondida el 12/09/2014 a las 21:47
fuente por usuario

votos
147

MVP no es necesariamente un escenario donde la Vista está a cargo (ver MVP de Taligent, por ejemplo).
Me parece desafortunado que las personas sigan predicando esto como un patrón (Ver a cargo) en oposición a un antipatrón porque contradice "Es solo una visión" (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 Views sea mucho más difícil y convenientemente excusa al diseñador de Microsoft de alentar las malas prácticas.

Para ser franco, creo que las preocupaciones subyacentes de MVC son ciertas para cualquier implementación de MVP y las diferencias son casi totalmente semánticas. Siempre que siga la separación de preocupaciones entre la vista (que muestra los datos), el controlador (que inicia 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 Supervisor Controlador? El único patrón real permanece como MVC, el resto son solo sabores diferentes de él.

Considere este artículo muy emocionante que enumera exhaustivamente varias de estas implementaciones diferentes. Puede notar que básicamente todos hacen lo mismo pero de forma ligeramente diferente.

Personalmente creo que MVP ha sido recientemente re-introducido como un término pegadizo para reducir las discusiones entre los fanáticos semánticos que argumentan si algo es verdaderamente MVC o no, o para justificar las herramientas de desarrollo de aplicaciones rápidas de Microsofts. Ninguna de estas razones en mis libros justifica su existencia como un patrón de diseño separado.

Respondida el 25/08/2008 a las 22:22
fuente por usuario

votos
85

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 algunas veces interactuará con el presentador, generalmente a través de alguna interfaz. Esto se reduce a la implementación; ¿Desea que la vista invoque métodos en el presentador o desea 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 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.

Respondida el 06/08/2008 a las 23:51
fuente por usuario

votos
58

introducir descripción de la imagen aquí

MVC (Modelo Vista Controlador)

La entrada se dirige al primer controlador, no la vista. Que de entrada puede provenir de un usuario que interactúa con una página, pero también podría ser de sólo introducir una URL específica en un navegador. En cualquier caso, es un controlador que está interconectado con dar inicio a algunas funciones. Existe una relación muchos-a-uno entre el controlador y la vista. Esto se debe a un solo controlador puede seleccionar diferentes vistas a ser prestados en base a la operación que está siendo ejecutado. Tenga en cuenta la flecha de un modo de controlador a la vista. Esto se debe a que la vista no tiene ningún conocimiento de o referencia al controlador. El controlador hace pasar de nuevo el modelo, por lo que no es de conocimiento entre la vista y el modelo esperado que se pasa en ella, pero no el controlador que sirve para arriba.

MVP (Modelo Vista Presentador)

La entrada comienza con la vista, no el presentador. Hay una correlació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 están disparando desde la vista, por lo que su conocimiento de la vista de su asociado. El presentador actualiza la vista sobre la base de las acciones solicitadas se realiza en el modelo, pero la vista no es el modelo conscientes.

Para mayor referencia

Respondida el 19/12/2015 a las 23:10
fuente por usuario

votos
31

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.

Cuando se utiliza la Vista pasiva, su Vista generalmente implementa una interfaz de grano fino con propiedades que se asocian más o menos directamente con el widget de IU subyacente. Por ejemplo, puede tener un ICustomerView con propiedades como Nombre y Dirección.

Su implementación podría verse más o menos 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 llama la "Vista pasiva". El beneficio es que la vista es fácil de probar, y es más fácil moverse entre plataformas UI (Web, Windows / XAML, etc.). La desventaja es que no se puede aprovechar cosas como el enlace de datos (que es realmente poderoso en frameworks como WPF y Silverlight ).

El segundo sabor de MVP es el Controlador Supervisor. En ese caso, su Vista podría tener una propiedad llamada Cliente, que de nuevo está vinculada a los widgets UI. No tiene que pensar en sincronizar y administrar micro la vista, y el Controlador Supervisor puede intervenir y ayudar cuando sea necesario, por ejemplo con una lógica completa de interacción.

El tercer "sabor" de MVP (o alguien podría llamarlo un patrón separado) es el modelo de presentación (o algunas veces se refiere a Model-View-ViewModel). Comparado con el MVP, "fusionas" el M y el P en una clase. Tiene su objeto de cliente al que están vinculados los widgets de UI, pero también tiene campos específicos de UI como "IsButtonEnabled" o "IsReadOnly", etc.

Creo que el mejor recurso que he encontrado para la arquitectura de UI es la serie de publicaciones de blog hechas por Jeremy Miller en The Build Your Own CAB Series Table of Contents . Cubrió todos los sabores de MVP y mostró el código C # para implementarlos.

También publiqué en mi blog sobre el patrón Model-View-ViewModel en el contexto de Silverlight en YouCard Re-visited: Implementación del patrón ViewModel .

Respondida el 08/08/2008 a las 06:55
fuente por usuario

votos
31
  • MVP = Modelo-Vista-Presentador
  • MVC = Modelo-Vista-Controlador

    1. Ambos patrones de presentación. Separa las dependencias entre un Modelo (piense en objetos de Dominio), su pantalla / página web (la Vista) y cómo se supone que se comporta su UI (Presentador / Controlador)
    2. Son bastante similares en concepto, la gente inicializa el Presentador / Controlador de manera diferente dependiendo del 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.
Respondida el 05/08/2008 a las 11:22
fuente por usuario

votos
15

Ambos marcos apuntan a separar las preocupaciones, por ejemplo, la interacción con una fuente de datos (modelo), la lógica de la aplicación (o convirtiendo estos datos en información útil) (Controlador / Presentador) y el código de visualización (Vista). En algunos casos, el modelo también se puede usar para convertir una fuente de datos en una abstracción de mayor nivel también. 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.

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

Para tal vez hacerse una idea de la distinción de ASP.NET MVC de MVP, vea esta presentación de MIX por Scott Hanselman.

Respondida el 05/08/2008 a las 11:20
fuente por usuario

votos
12

Ambos son patrones que intentan separar la lógica de presentación y de negocios, 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 el enfoque basado en el controlador frontal. Eso significa que en el estándar MVP, el ciclo de vida de la página de formularios web se ha mejorado simplemente extrayendo la lógica de negocio del código. En otras palabras, la página es la única solicitud de servicio http. En otras palabras, MVP en mi humilde opinión es un tipo de mejora evolutiva de formulario web. MVC por otra parte cambia completamente el juego porque la solicitud es interceptada por la clase del controlador antes de cargar la página, la lógica de negocio se ejecuta allí y luego en el resultado final del controlador procesando los datos que acaban de arrojar a la página ("vista"). sentido, MVC se ve (al menos para mí) mucho para Supervisar el sabor del Controlador de MVP mejorado con el motor de enrutamiento

Ambos habilitan TDD y tienen inconvenientes y ventajas.

La decisión sobre cómo elegir uno de ellos en mi humilde opinión debe basarse en la cantidad de tiempo que se invierte en el tipo de desarrollo web ASPNET web form. Si uno se considerara bueno en los formularios web, sugeriría MVP. Si uno no se siente 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

Respondida el 21/09/2008 a las 13:32
fuente por usuario

votos
11

Cada uno de ellos se dirige a diferentes problemas e incluso pueden ser combinados entre sí para tener algo como más adelante

La diseños combinados

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

Respondida el 13/03/2017 a las 02:54
fuente por usuario

votos
9

Algo que no entiendo es por qué el enlace de datos tiene que reducir la capacidad de prueba. Quiero decir, una vista se basa efectivamente en lo que podría considerarse como una o más vistas de bases de datos, ¿verdad? Puede haber conexiones entre filas en diferentes vistas. Alternativamente, podemos hablar orientado a objetos en lugar de relacional, pero eso en realidad no cambia nada, todavía tenemos una o más entidades de datos distintas.

Si vemos la programación como estructuras de datos + algoritmos, entonces ¿no sería mejor tener las estructuras de datos lo más explícitas posibles, y luego desarrollar algoritmos de los cuales cada uno dependa de una información tan pequeña como sea posible, con un mínimo acoplamiento entre los algoritmos? ?

Siento patrones de pensamiento FactoryFactoryFactory muy similares a los de Java: queremos tener múltiples vistas, múltiples modelos, múltiples grados de libertad por todos lados. Es casi como que es la fuerza impulsora detrás de MVC y MVP y todo eso. Ahora déjame preguntarte: ¿con qué frecuencia vale la pena el costo que pagas por esto (y definitivamente hay un costo)?

Tampoco veo ninguna discusión sobre cómo administrar de manera eficiente el estado entre las solicitudes HTTP. ¿Acaso no hemos aprendido de la gente funcional (y de los voluminosos errores cometidos por los spaghetti imperativos) que el estado es malo y debe minimizarse (y cuando se usa, se debe entender bien)?

Veo mucho uso de los términos MVC y MVP sin mucha evidencia de que la gente piense críticamente sobre ellos. Claramente, el problema es "ellos", yo, o ambos ...

Respondida el 28/01/2009 a las 22:11
fuente por usuario

votos
8

Hay muchas respuestas a la pregunta, pero me sentí existe una necesidad de alguna respuesta muy simple comparación con claridad los dos. Aquí está la discusión que hice cuando un usuario busca un nombre de la película en una aplicación MVP y MVC:

Usuario: Haga clic clic ...

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

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

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

( Ver llamando al presentador | controlador ...) [ MVP | MVC ]

Ver : Hey Presentador | Controlador , un usuario simplemente ha hecho 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 , por su parte ... Estoy buscando el término de búsqueda en el modelo , por favor mostrar él / ella una barra de progreso [ MVP | MVC ]

( Presentador | controlador está llamando el Modelo ...) [ MVP | MVC ]

Presentador | Controlador : Hey modelo , ¿Tiene usted algún problema para este término de búsqueda ?: “piano” [ MVP | MVC ]

Modelo : Hey Presentador | Controlador , déjame ver ... [ MVP | MVC ]

( 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 : He encontrado una lista para usted, Presentador , aquí está en JSON “[{ "name": "Profesor de piano", "año": 2001}, { "name": "Piano", "año": 1993} ]”[ MVP ]

Modelo : Hay algún resultado disponible, Controlador . He creado una variable de campo en mi ejemplo, y lo llenó con el resultado. Su nombre es "searchResultsList" [ MVC ]

( Presentador | Controlador gracias Modelo y obtiene de nuevo a la vista ) [ MVP | MVC ]

Presentador : Gracias por la espera Ver , he encontrado una lista de resultados coincidentes para usted y los colocó en un formato presentable: [ "Profesor de piano 2001", "Piano 1993"]. Por favor mostrarlo al usuario en una lista vertical. También por favor ocultar la barra de progreso ahora [ MVP ]

Controlador : Gracias por la espera Ver , he pedido Modelo sobre la consulta de búsqueda. Se dice que ha encontrado una lista de resultados que corresponden y los almacena en una variable denominada "searchResultsList" dentro de su instancia. Se puede llegar desde allí. También por favor ocultar la barra de progreso ahora [ MVC ]

Ver : Muchas gracias Presentador [ MVP ]

Ver : Gracias "Controller" [ MVC ] (Ahora la vista está cuestionando en sí: ¿Cómo debería presentar los resultados que recibo de la Modelo ? Al usuario Si el año de la producción de la película lo 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 de los patrones de aplicaciones arquitectónicas (MVC, MVP, VMTP, arquitectura limpia, ...) acompañados de un acuerdo de recompra Github aquí . A pesar de que la muestra está escrito para android, los principios subyacentes se pueden aplicar a cualquier tipo de soporte.

Respondida el 06/04/2018 a las 10:51
fuente por usuario

votos
8

En androide existe versión del MVC que es MVP: ¿Cuál es MVP?

El patrón MVP permite separar la capa de presentación de la lógica, de modo que todo lo relacionado con el funcionamiento de la interfaz se separa de cómo lo representamos en la pantalla. Idealmente, el patrón MVP sería lograr esa misma lógica podría tener completamente diferentes e intercambiables vistas.

Primero que hay que aclarar es que MVP no es un patrón arquitectónico, es sólo responsable de la capa de presentación. En cualquier caso, siempre es mejor utilizarlo para su arquitectura que no usarlo en absoluto.

Un ejemplo de MVP es https://github.com/antoniolg/androidmvp

¿Cuál es MVC? arquitectura MVC es uno de los patrones más antiguos disponibles para lograr la separación de preocupaciones. MVC se compone de tres capas, a saber, Modelo, Vista y Controlador.

MVC clásico existía en un momento en que todos los controles / gadget que existía en la pantalla se considera tonto y cada control se empareja con su propio controlador para gestionar las interacciones de los usuarios que ocurren en ellos. Así que si existen aparatos 10, entonces 10 controladores tienen que existir. En este escenario, todos los aparatos se cuenta como una vista. El advenimiento de los sistemas de Windows GUI cambió esta imagen. La relación Control-Controller se hizo obsoleto. Controles ganaron la inteligencia para responder a las acciones iniciadas por el usuario. En el mundo de Windows, vista es una superficie en la que se dan todas las controles / aparatos, por lo tanto, existe una necesidad para un solo controlador. Ver puede recibir eventos y llegar a los controladores ayudan a hacer su posterior procesamiento.

Código de ejemplo para MVC en androide http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

Diferencia entre ambos está disponible aquí http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Ahora desde mi experiencia debe utilizar MVP de proyecto basado androide, porque versión mejorada del modelo MVC.

Respondida el 02/07/2016 a las 04:15
fuente por usuario

votos
8

He usado tanto MVP como MVC y, aunque 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 estoy trabajando en un equipo que ya tiene una buena base en el estilo de desarrollo de formularios web, es mucho más fácil introducir 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

Respondida el 02/01/2009 a las 11:35
fuente por usuario

votos
7

En MVP la vista extrae datos desde el presentador que extrae y se prepara / normaliza los datos a partir del modelo, mientras que en MVC el controlador extrae datos desde el modelo y establece, por empuje en la vista.

En el MVP se puede tener una visión única de trabajar con varios tipos de presentadores y un único presentador de trabajar con diferentes puntos de vista múltiples.

MVP por lo general utiliza algún tipo de un marco vinculante, como marco vinculante Microsoft WPF o varios marcos de unión para HTML5 y Java.

En esos marcos, la interfaz de usuario / HTML5 / XAML, es consciente de lo que la propiedad de la presentadora de cada elemento se muestra la interfaz de usuario, por lo que cuando se enlaza un objeto de un presentador, la vista se dirige a las propiedades y sabe cómo dibujar datos de ellos y cómo para establecer cuando se cambia un valor en la interfaz de usuario por parte del usuario.

Así, si por ejemplo, el modelo es un coche, a continuación, el presentador es una especie de un presentador de coche, expone las propiedades de automóviles (año, fabricante, asientos, etc.) a la vista. La vista sabe que el campo de texto llamado 'fabricante de automóviles' tiene que mostrar la propiedad presentador Maker.

A continuación, puede unirse a la vista de muchos tipos diferentes de presentador, todos deben tener la propiedad Maker - que puede ser de un avión, tren o lo que sea, la vista no le importa. La vista obtiene datos de la presentadora - no importa lo que - siempre y cuando se implementa una interfaz acordado.

Este marco vinculante, si se tira hacia abajo, que es en realidad el controlador :-)

Y así, se puede ver el MVP como una evolución del MVC.

MVC es grande, pero el problema es que por lo general su controlador por visión. Un controlador sabe cómo establecer campos de visión A. Si ahora, desea Ver A para visualizar los datos del modelo B, necesita un controlador para conocer el modelo B, o necesita un controlador para recibir un objeto con una interfaz - que es como MVP sólo que sin las ataduras, o si necesita volver a escribir el código programado de la interfaz de usuario en el controlador B.

Conclusión - MVP y MVC son tanto desacople de los patrones de interfaz de usuario, pero MVP lo general utiliza un marco fijaciones que es MVC debajo. ASI MVP está en un nivel de arquitectura más alto que MVC y un patrón de envoltura por encima de MVC.

Respondida el 07/06/2013 a las 22:16
fuente por usuario

votos
6

Mi visión a corto humilde: MVP es para grandes escalas, y MVC de escamas diminutas. Con MVC, I en algún momento siento de la V y la C puede ser visto a dos caras de un único componente indivisible más bien unido directamente a M, y uno cae inevitablemente a esta cuando se va abajo-a escalas más cortos, como los controles de interfaz de usuario y widgets de base. A este nivel de granularidad, MVP tiene poco sentido. Cuando uno, por el contrario ir a escalas mayores, la interfaz adecuada se vuelve más importante, con la misma asignación inequívoca de responsabilidades, y aquí viene MVP.

Por otro lado, esta regla escala de un pulgar, puede pesar muy poco cuando las características de la plataforma favorece algún tipo de relaciones entre los componentes, al igual que con la web, donde parece ser más fácil de implementar MVC, más de MVP.

Respondida el 20/02/2013 a las 17:55
fuente por usuario

votos
5

Modelo-Vista-Controlador

MVC es un patrón para la arquitectura de una aplicación de software. Se separan la lógica de la aplicación en tres partes separadas, la promoción de la modularidad y la facilidad de colaboración y reutilización. También hace que las aplicaciones más flexible y acogedor para iterations.It separa una aplicación en los siguientes componentes:

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

Para hacer esto un poco más claro, imaginemos una aplicación simple lista de compras. Todo lo que queremos es una lista del nombre, cantidad y precio de cada artículo que necesitamos para comprar esta semana. A continuación vamos a describir cómo podríamos implementar algunas de esta funcionalidad utilizando MVC.

introducir descripción de la imagen aquí

Modelo-Vista-Presentador

  • El modelo es los datos que se muestra en la vista (interfaz de usuario).
  • La vista es una interfaz que muestra los datos (el modelo) y comandos de rutas de usuario (eventos) al presentador para actuar sobre los datos. La vista por lo general tiene una referencia a su presentador.
  • El presentador es el “medio-hombre” (interpretado por el controlador en MVC) y tiene referencias tanto, ver y modelo. Tenga en cuenta que la palabra “modelo” es engañosa. Más bien debería ser la lógica empresarial que recupera o manipula un modelo . Por ejemplo: Si usted tiene una base de datos de almacenamiento de usuario en una tabla de base de datos y su Ver quiere mostrar una lista de usuarios, entonces el presentador tendría una referencia a la lógica de negocio de base de datos (como un DAO) de donde el presentador se consulta una lista de los usuarios.

Si desea ver una muestra con aplicación sencilla compruebe este mensaje github

Un flujo de trabajo concreto de consultar y mostrar una lista de usuarios a partir de una base de datos podría funcionar así: introducir descripción de la imagen aquí

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

patrón MVC

  • Controlador se basan en comportamientos y puede ser compartido a través de puntos de vista

  • Puede ser responsable de determinar qué vista para mostrar (Front Controller Patrón)

patrón MVP

  • Ver más libremente se acopla al modelo. El presentador es responsable de la unión del modelo a la vista.

  • Más fácil de prueba de la unidad debido a la interacción con la vista es a través de una interfaz

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

Respondida el 29/11/2017 a las 07:14
fuente por usuario

votos
3

Hay muchas versiones de MVC, esta respuesta es acerca de la MVC original en Smalltalk. En resumen, es imagen de la MVC vs MVP

Esta charla Droidcon NYC 2017 - Diseño de aplicación Limpiar con componentes de la arquitectura lo aclara

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

Respondida el 09/09/2015 a las 02:34
fuente por usuario

votos
0

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

Lo que creo es MVP es una versión mejorada del MVC en el que básicamente separar la preocupación de cómo vas a mostrar los datos que tiene. Presentador incluye un poco la lógica de negocio de la interfaz de usuario y habla a través de una interfaz que hace que sea más fácil para poner a prueba su lógica de negocio de interfaz de usuario a través de diferentes puntos de vista. MVC todavía habla a través de interfaces (límites) para capas de pegamento pero no tiene tal restricción para imponer la lógica de presentación de interfaz de usuario. Aparte de eso, yo no veo ningún más diferencias.

Respondida el 25/01/2018 a las 18:24
fuente por usuario

votos
0

MVP

MVP significa Modelo - Ver- Presentador. Esto llegó a imaginarse a principios de 2007 en el que Microsoft introdujo aplicaciones inteligentes cliente de Windows.

Presentador está actuando como un papel de supervisión en el que MVP View y lógica de negocio a partir de modelos de unión.

Ver suceso de unión se llevará a cabo en el presentador de una interfaz de vista.

Ver es el iniciador de las entradas del usuario y luego los delegados a los eventos presentador y conductor maneja enlaces de eventos y obtener datos de modelos.

Pros: Vista está teniendo única interfaz de usuario de ninguna lógica de alto nivel de capacidad de prueba

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

MVC

MVC significa Modelo-Vista-Controlador. Controlador es responsable de la creación de modelos y haciendo puntos de vista con los modelos de unión.

Controller es el iniciador y decide que ver para rendir.

Pros: énfasis en la responsabilidad individual Principio alto nivel de capacidad de prueba

Contras: A veces demasiada carga de trabajo para los controladores, si se intenta representar múltiples puntos de vista en mismo controlador.

Respondida el 12/01/2016 a las 01:50
fuente por usuario

votos
-1

La respuesta más simple es la forma en la vista interactúa con el modelo. En el MVP del modelo se une a la presentadora, que es responsable de actualizar la vista. En el modelo MVC actualiza la vista directa.

Respondida el 16/11/2017 a las 14:32
fuente por usuario

votos
-2

Aquí publicado anteriormente es una sumatoria de fracaso y la incapacidad del hombre para entender el protocolo de enlace simple entre dos máquinas. Voy a explicar el uso del sentido común para tratar de despertar a todos ustedes desde el idealismo de estos delirantes que han encontrado su camino en las mentes de aquellos que desean crear ellos. Y tan tonto como todos estos procesos de sonido, de hecho es el modelo de objetos (que es el archivo HTML) está solicitado por la máquina cliente. Aquí es cómo todo se reduce.

  1. Un hipervínculo es presionado y una única solicitud se envía por la máquina del cliente al servidor. El servidor responde a esa petición con una respuesta enviando el modelo de objetos al Cliente. (Conocido simplemente como "respuesta").
  2. El servidor responde enviando un Object Model (El archivo HTML) a la máquina del cliente (Conocido como un apretón de manos completa).
  3. El navegador Los clientes ahora pueden hacer que el "Vista" mediante el análisis, léxico / tokenizing, y convertir ese modelo de objetos de marcado en una interfaz gráfica de usuario "Vista".

I puede ser retirado ahora, pero por Gosh ustedes aquí están discutiendo y debatiendo disparate. Y, honestamente, no importa lo que se llama un apretón de manos entre dos máquinas no puede ser cualquier cosa fuera de una petición única, una única respuesta del "modelo" de objetos y, finalmente, la representación clientes de explorador "Ver".

Y para terminar, una vista no existe en un apretón de manos. El modelo de objetos sólo está marcado para el navegador para convertir a la interfaz gráfica de usuario conjuntos de widgets y métodos Eval por tres o más modelos de objetos. HTML, CSS y JavaScript. Y no importa lo mucho que nadie pueda decir un servidor hace algo fuera de lo común es el caballo de estiércol.

El "Servidor" no es el "controlador" es una Directer y sólo dirige la respuesta mediante el envío de una respuesta del objeto "Modelo". El navegador del cliente (que sería la probable Controller) crea entonces la opción "Ver" del "modelo" de objetos del servidor no tiene nada que ver con esto. Su lengua ordenador no puede entrar en el modelo de objetos en absoluto ni delegarla. Todo lo que es es un creador de marcado.

todo el lío es simplemente un navegador del lado del cliente "Controller" que analiza el "modelo" para hacer que la "Vista" o CMV o MCV (enviado como modelo de primer orden) y no puedes cambiarlo. Pero se le puede llamar simplemente una solicitud, Object Model Respuesta y Render Ver o RRMV.

Respondida el 31/12/2018 a las 02:10
fuente por usuario

votos
-2

Mucha gente no sabe exactamente cuál es la diferencia entre el controlador y el presentador de MVC y MVP respectivamente.

su una simple ecuación donde

MVC Ver = Ver y Presentador del MVP

MVP Modelo = Controller y el modelo de MVC

Más información se refieren a este http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

Respondida el 31/07/2017 a las 07:13
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more