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

Al mirar más allá del RAD (arrastrar-soltar y configurar) forma de construir interfaces de usuario que muchas herramientas le animan, es probable que encuentre tres patrones de diseño llamados Controlador de vista de modelo, Modelo-Vista-Presentador y Modelo-Vista-VistaModelo. Mi pregunta tiene tres partes:

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

preguntado el 05 de agosto de 08 a las 08:08

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

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

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

Se les llama patrones arquitectonicos no patrones de diseño. Si quiere saber la diferencia, marque este -

24 Respuestas

Modelo-Vista-Presentador

In MVP, el presentador contiene la lógica empresarial de la interfaz de usuario para la vista. Todas las invocaciones del delegado de 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 burlarse de la Vista en una prueba unitaria. Un atributo común de MVP es que tiene que haber una gran cantidad de distribución 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 haya completado el guardado, el Presentador volverá a llamar 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 presentaciones separadas en WebForms. La razón es que la vista siempre la crea primero el tiempo de ejecución de ASP.NET. Usted puede más información sobre ambas variantes.

Dos variaciones principales

Vista pasiva: La vista es lo más tonta posible y casi no contiene lógica. Un 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 un enlace de datos directo, en cambio, la Vista expone las propiedades del setter que el Presentador usa para configurar los datos. Todo el estado se gestiona 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 setter) 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, el trabajo del presentador es pasar el modelo a la vista para que se pueda vincular a él. El presentador también contendrá lógica para gestos como presionar un botón, navegación, etc.

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

Controlador de vista de modelo

En la 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 en el otro lado de la 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 -> Llamada al controlador -> Lógica del controlador -> El controlador devuelve la Vista.

Otra gran diferencia sobre MVC es que la Vista no se vincula directamente con el Modelo. La vista simplemente se renderiza 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 a 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ó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 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. 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 los comandos que utiliza la vista 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-VistaModelo.

Hay un Artículo de MSDN sobre el modelo de presentación y una sección en el Guía de aplicaciones compuestas para WPF (ex Prisma) acerca de Patrones de presentación separados

Respondido 12 ago 20, 18:08

¿Puede aclarar esta frase? 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. Para mí, suena como lo mismo, pero estoy seguro de que estás describiendo algo diferente. - Panzercrisis

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

Tenga en cuenta que MVC es utilizado a menudo por web-frameworks como Laravel, donde las solicitudes de URL recibidas (tal vez hechas por los usuarios) son manejadas por el Controller y el HTML generado por el View se envía al cliente - Entonces, el View Es una parte del backend y el usuario nunca puede acceder a él directamente, y si experimenta lo contrario en cualquier lugar, considérelo como una extensión MVC (o incluso una violación). @Panzercrisis, esto difiere de MVP (como el usado en Android SO) donde actions route through the View to the Presenter y el usuario tiene acceso directo a la View. - Top Master

Lo que el autor describe cuando habla de MVC no es el Smalltalk MVC original (cuyo flujo es triangular) sino el "Web MVC" donde el controlador representa una vista usando un modelo y se la devuelve al usuario. Creo que vale la pena señalar esto porque crea mucha confusión. - raiks

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

MVC

MVC

MVP

enter image description here

Respondido 06 Jul 13, 23:07

Esta es una excelente descripción del esquema, que muestra la abstracción y el aislamiento completo de cualquier GUI relacionado (ver cosas) de la API del presentador. Un punto menor: se podría usar un presentador maestro cuando solo haya un presentador, en lugar de uno por vista, pero su diagrama es el más limpio. En mi opinión, la mayor diferencia entre MVC / MVP es que MVP intenta mantener la vista totalmente vacía de cualquier otra cosa que no sea la visualización del 'estado de la vista' actual (datos de la vista), al mismo tiempo que no permite a la vista ningún conocimiento de los objetos del modelo. Por lo tanto, las interfaces, que necesitan estar allí, inyectan ese estado. - usuario2080225

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

El ejemplo de MVC es incorrecto; existe una relación estricta de 1: 1 entre las vistas y los controladores. Por definición, un controlador interpreta la entrada de gestos humanos para producir eventos para el modelo y ver por igual para un solo control. Más simplemente, MVC fue diseñado para su uso con widgets individuales únicamente. Un widget, una vista, un control. - Samuel A. Falvo II

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

@StuperUser: no estoy seguro de lo que estaba pensando cuando escribí eso. Tiene razón, por supuesto, y mirando hacia atrás en lo que escribí, me pregunto si tenía algún otro contexto en mente que no logré articular. Gracias por la corrección. - Samuel A. Falvo II

Escribí en un blog sobre esto hace un tiempo, citando en 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á acoplada de forma más flexible al modelo. El presentador es responsable de vincular el modelo a la vista.
  • Más fácil de realizar pruebas unitarias porque la interacción con la vista se realiza a través de una interfaz
  • Por lo general, ver el mapa de presentador uno a uno. Las vistas complejas pueden tener varios presentadores.

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.

contestado el 04 de mayo de 15 a las 04:05

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

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

Originalmente, hay dos tipos de controladores: el que dijo que se comparte en múltiples vistas, y los que son vistas específicas, principalmente con el propósito de adaptar la interfaz del controlador compartido. - acsor

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

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

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

enter image description here

enter image description here

Respondido el 12 de Septiembre de 14 a las 21:09

Tengo una pregunta sobre el diagrama MVC. No obtengo la parte donde la vista sale para buscar datos. Creo que el controlador reenviaría a la vista con los datos necesarios. - Brian Rizo

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

Sé que esta es una respuesta antigua, pero ¿alguien podría responder en el punto de @JonathanLeaders? Vengo de un entorno de winforms, a menos que haya realizado una codificación única, cuando hace clic en la interfaz de usuario / Ver, se conoce ese clic antes que nada. ¿Al menos, hasta donde yo sé? - Rob P.

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

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

MVP es no necesariamente un escenario donde la Vista está a cargo (ver MVP de Taligent, por ejemplo).
Me parece desafortunado que la gente todavía esté predicando esto como un patrón (Vista a cargo) en lugar de un anti-patró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 fomentar las malas prácticas.

Para ser perfectamente franco, creo que las preocupaciones subyacentes de MVC son ciertas 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 está logrando los beneficios de MVC . Si está logrando los beneficios, ¿a quién realmente le importa si su patrón es MVC, MVP o Supervising Controller? El único reales El patrón permanece como MVC, el resto son solo diferentes sabores.

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

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

Respondido 02 Abr '20, 18:04

He leído varias respuestas y blogs sobre las diferencias entre MVC / MVP / MVVM / etc '. De hecho, cuando estás en el negocio, todo es lo mismo. Realmente no importa si tiene una interfaz o no, y si está usando un configurador (o cualquier otra característica del idioma). Parece que la diferencia entre estos patrones nació de la diferencia de las implementaciones de varios marcos, más que de una cuestión de concepto. - Michael

Yo no llamaría MVP un antipatrón, como más adelante en la publicación "... el resto [incluido MVP] son ​​solo sabores diferentes de [MVC] ..", lo que implicaría que si MVP fuera un anti-patrón, también lo fue MVC ... es solo un sabor para enfoque de un marco diferente. (Ahora, algunos soluciones Las implementaciones de MVP pueden ser más o menos deseables que algunas soluciones Implementaciones MVC para diferentes tareas ...) - user166390

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

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

Samuel, por favor, aclara de qué estás hablando. A menos que me cuentes la historia del equipo que "inventó" MVC, entonces tengo muchas dudas sobre tu texto. Si solo está hablando de WinForm, entonces hay otras formas de hacer las cosas y he creado proyectos de WinForm donde los enlaces de control son administrados por el controlador, no por "controles individuales". - Quisquilloso

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; ¿Quiere que la vista llame a métodos en el presentador o desea que la vista tenga eventos que el presentador escucha? Todo se reduce a esto: la vista conoce al 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. 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 administra la vista; la vista es esclava del controlador. La vista no conoce el controlador.

Respondido el 20 de junio de 20 a las 10:06

"View no conoce el controlador". Creo que quieres decir que la vista no tiene contacto directo con el modelo. - Lotus Notes

La vista nunca debería saber sobre el modelo en ninguno de los dos. - Brian Leahy

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

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

MVC en iOS, MVP en Android es un buen lugar para comenzar: mert kahraman

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 podría provenir simplemente de ingresar una URL específica en un navegador. En cualquier caso, es un controlador con el que se interactúa 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 renderizar en función de la operación que se está ejecutando. Tenga en cuenta la flecha unidireccional de Controlador a 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 pasa a él, pero no el controlador que lo entrega.

MVP (presentador de vista de modelo)

La entrada comienza con la Vista, no con el Presentador. Existe un mapeo uno a uno entre la Vista y el Presentador asociado. La vista tiene una referencia al presentador. El presentador también está reaccionando a los eventos que se desencadenan desde la vista, por lo que es consciente de la vista con 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 reconoce el modelo.

Para obtener más Referencia

Respondido el 20 de diciembre de 15 a las 02:12

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

¿Un enlace de Model to View en MVC? Es posible que desee editar su respuesta para explicar cómo esto lo convierte en un sistema 'desacoplado', dado este enlace. Sugerencia: puede que le resulte difícil. Además, a menos que piense que el lector aceptará felizmente que han estado calculando mal toda su vida, es posible que desee explicar por qué las acciones pasan primero por Controller en MVC a pesar de que el usuario interactúa con los elementos 'visuales' en la pantalla View), no una capa abstracta detrás del procesamiento. - Ceniza

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

Estoy de acuerdo con Ash y MegaManX. En el diagrama MVC, la flecha debe ser desde la Vista apuntando al Modelo (o ViewModel, o DTO), no desde el Modelo a la Vista; porque el modelo no conoce la vista, pero es posible que la vista conozca el modelo. - jboy bandera

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: haga clic en haga clic en ...

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 llamando al Presentador|Normativa …) [MVP|MVC]

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

Presentador|Normativa: Oye Ver, ¿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 tanto, busco el término de búsqueda en el Modelo, enséñele una barra de progreso [MVP|MVC]

( Presentador|Normativa está llamando al Modelo …) [MVP|MVC]

Presentador|Normativa: Oye Modelo, ¿Tiene alguna coincidencia para este término de búsqueda ?: "piano" [MVP|MVC]

Modelo: Oye Presentador|Normativa, 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 “[{" nombre ":" Profesor de piano "," año ": 2001}, {" nombre ":" Piano "," año ": 1993}]” [MVP]

Modelo: Hay algún resultado disponible, Normativa. He creado una variable de campo en mi instancia y la he llenado con el resultado. Su nombre es "searchResultsList" [MVC]

(Presentador|Normativa gracias Modelo y vuelve al Ver) [MVP|MVC]

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

Normativa: Gracias por esperar Ver, He preguntado Modelo acerca de 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 ahí. También oculte la barra de progreso ahora [MVC]

Ver: Muchas gracias Presentador [MVP]

Ver: Gracias "Controlador" [MVC] (Ahora el Ver se está cuestionando: ¿Cómo debo presentar los resultados que obtengo de la Modelo al usuario? ¿Debería ser el año de producción de la película 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 sobre patrones arquitectónicos de aplicaciones (MVC, MVP, MVVP, arquitectura limpia, ...) acompañados de un repositorio de Github. aquí. Aunque la muestra está escrita para Android, los principios subyacentes se pueden aplicar a cualquier medio.

Respondido 06 Abr '18, 14:04

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

@Radu, No, no microgestiona, eso es lo que hace el presentador al hacer que la vista sea pasiva o tonta - Alí Nem

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

Controlador de vista de modelo

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, lo que promueve 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 empresarial
  • Controlador para manejar la interfaz de usuario y la aplicación
  • Vistas para manejar objetos y presentaciones de la interfaz gráfica de usuario

Para dejar esto un poco más claro, imaginemos una aplicación de lista de compras simple. 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 algunas de estas funciones utilizando MVC.

enter image description here

Modelo-Vista-Presentador

  • El modelo son los datos que se mostrarán en la vista (interfaz de usuario).
  • El VER es una interfaz que muestra datos (el modelo) y enruta los 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. Debería ser más bien lógica empresarial que recupera o manipula un modelo. Por ejemplo: si tiene una base de datos que almacena Usuario en una tabla de base de datos y su Vista quiere 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 una muestra con una implementación simple, consulte este Publicación de GitHub

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

¿Qué es diferencias entre MVC y MVP ¿patrones?

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 de controlador frontal)

Patrón MVP

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

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

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

Respondido el 13 de junio de 19 a las 08:06

No, no hay una conexión directa entre la vista y el modelo en MVC. tu diagrama es incorrecto. - gratis

  • 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 interfaz de usuario (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 tiene el modelo actualizando la vista.

Respondido 20 Abr '13, 10:04

Modelo actualizando el VIew. ¿Y esto sigue siendo un sistema desacoplado? - Ceniza

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

Cuando usa 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, 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 "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 puede aprovechar cosas como el enlace de datos (que es democracia 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 nuevamente está vinculada a los datos de los widgets de la interfaz de usuario. No tiene que pensar en sincronizar y micro-administrar la vista, y el controlador supervisor puede intervenir y ayudar cuando sea necesario, por ejemplo, con la lógica de interacción completa.

El tercer "sabor" de MVP (o alguien tal vez lo llamaría un patrón separado) es el Modelo de presentación (o algunas veces se hace referencia a Modelo-Vista-VistaModel). En comparación con el MVP, "fusionas" la M y la P en una clase. Tiene su objeto de cliente al que están vinculados los widgets de la 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 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 escrito en un blog sobre el patrón Model-View-ViewModel en el contexto de Silverlight en YouCard Re-Visit: Implementación del patrón ViewModel.

contestado el 04 de mayo de 15 a las 04:05

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

El patrón combinado

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

respondido 13 mar '17, 05:03

En lugar de complicar demasiado las cosas, podría haber respondido la pregunta. Por eso la mayoría de nosotros estamos aquí. Busqué una comparación entre mvp y mvc y fue redirigido aquí y estás hablando de la armonía de esas arquitecturas que no está relacionada con OP. - Farid

Ambos marcos apuntan a preocupaciones separadas, 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 el código de visualización (Vista). 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.

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

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

Respondido 05 ago 08, 11:08

MVC y MVP son patrones, no marcos. Si piensa honestamente, ese tema era sobre .NET framework, entonces es como escuchar "Internet" y pensar que se trata de IE. - tereško

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

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 Page Controller donde MVC es un enfoque basado en Front Controller. Eso significa que, en MVP, el ciclo de vida de la página de formulario web estándar 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 de formulario web. MVC, por otro lado, cambia completamente el juego porque la solicitud es interceptada por la clase del controlador antes de que se cargue la página, la lógica de negocios se ejecuta allí y luego, al final, el controlador procesa los datos que se acaban de descargar 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 ventajas y desventajas.

La decisión sobre cómo elegir uno de ellos en mi humilde opinión debería basarse en cuánto tiempo se invirtió en el tipo de formulario web ASP NET de desarrollo web. Si uno se considera bueno en 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 forma de hacerlo.

Aquí hay otro enlace de publicación de blog que ofrece 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

Respondido el 22 de Septiembre de 08 a las 08:09

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

Respondido el 02 de enero de 09 a las 10:01

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

En MVP puede tener una sola 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 del presentador Maker.

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

Y entonces, puede 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 los 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 sin los enlaces, o necesita reescribir el código del conjunto de IU en el Controlador B.

Conclusión: MVP y MVC son ambos desacopladores de los patrones de IU, pero MVP generalmente usa un marco de enlaces que es MVC debajo. ASÍ MVP se encuentra en un nivel arquitectónico más alto que MVC y un patrón de envoltura por encima de MVC.

contestado el 04 de mayo de 15 a las 04:05

Mi humilde visión corta: 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 solo componente indivisible bastante directamente ligado a M, y uno inevitablemente cae en esto cuando se baja a escalas más cortas, como controles de interfaz de usuario y widgets básicos. En este nivel de granularidad, MVP tiene poco sentido. Cuando uno, por el contrario, pasa 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 de escala, puede pesar muy poco cuando las características de la plataforma favorecen algún tipo de relaciones entre los componentes, como ocurre con la web, donde parece ser más fácil implementar MVC, más que MVP.

Respondido 20 Feb 13, 16:02

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

Esta charla droidcon NYC 2017: diseño de aplicaciones limpias con componentes de arquitectura lo aclara

enter image description here enter image description here

respondido 14 nov., 17:14

En MVC, el modelo nunca se llama directamente desde la vista: Rodas

Esta es una respuesta inexacta. No se deje engañar. como escribe @rodi, no hay interacción entre la Vista y el Modelo. - shawn mehan

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

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

¿Qué significan las flechas? - problema oficial

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

imagen que explica MVC, MVP y MVVM - por Erwin Vandervalk

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

contestado el 10 de mayo de 19 a las 02:05

La respuesta más simple es cómo interactúa la vista con el modelo. En MVP, la vista es actualizada por el presentador, 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 comercial requerida y luego actualiza la vista. En MVC, el modelo actualiza la vista directamente en lugar de volver a través del controlador.

respondido 22 mar '20, 08:03

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

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

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

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

No hay este bonito video del tío Bob donde explica brevemente MVC & 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 lo vas a mostrar (la vista). El presentador incluye un poco la lógica comercial 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 que se introduce (solo usando establecedores). Su principal beneficio es que puede probar la lógica de negocios de su interfaz de usuario contra muchas / varias 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 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.

respondido 31 mar '20, 21:03

Punto importante del tío Bob: cuando Trygve Reenskaug lo inventó originalmente, MVC estaba destinado a cada widget no todo el formulario. - Albahaca bourque

Te olvidaste de Acción-Dominio-Respondedor (ADR).

Como se explica en algunos gráficos anteriores, existe una relación / vínculo directo entre el Modelo y Ver en MVC. Se realiza una acción en el Normativa, que ejecutará una acción en el Modelo. Esa acción en el Modelo, desencadenará una reacción en la Ver. los Ver, siempre se actualiza cuando el ModeloCambios de estado.

Algunas personas siguen olvidando que MVC fue creado a finales de los 70 ", y que la Web solo se creó a finales de los 80 "/ principios de los 90". MVC no se creó originalmente para la Web, sino para aplicaciones de escritorio, donde el controlador, el modelo y la vista coexistirían juntos.

Porque usamos frameworks web (p.ej:. Laravel) que todavía usan las mismas convenciones de nomenclatura (modelo-vista-controlador), tendemos a pensar que debe ser MVC, pero en realidad es otra cosa.

En su lugar, eche un vistazo a Acción-Dominio-Respondedor. En ADR, el Normativa obtiene un Acción, que realizará una operación en el Modelo / Dominio. Hasta ahora, igual. La diferencia es que luego recopila la respuesta / datos de esa operación y la pasa a un Responder (p.ej:. view()) para renderizar. Cuando se solicita una nueva acción en el mismo componente, el Normativa se llama de nuevo y el ciclo se repite. En ADR, hay sin conexión entre el modelo / dominio y la vista (Respuesta del respondedor).

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

Respondido 22 Oct 19, 11:10

En pocas palabras,

  • En MVC, View tiene la parte UI, que llama al controlador, que a su vez llama al modelo y al modelo, a su vez, vuelve a activar los eventos para que se visualicen.
  • En MVP, View contiene UI y llama al presentador para la parte de implementación. El presentador llama a la vista directamente para obtener actualizaciones de la parte de la interfaz de usuario. El presentador llama al modelo que contiene lógica empresarial y no hay interacción alguna con la vista. Así que aquí el presentador hace la mayor parte del trabajo :)

Respondido 25 ago 20, 16:08

MVP

MVP son las siglas de Model - View- Presenter. Esto llegó a una imagen a principios de 2007 en la que Microsoft introdujo aplicaciones de Windows Smart Client.

Un presentador actúa como un rol de supervisión en MVP que vincula los eventos de View y la lógica de negocios de los modelos.

La vinculación de eventos de visualización se implementará en el Presentador desde una interfaz de visualización.

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

Pros: La vista solo tiene una interfaz de usuario, no ninguna lógica.Alto nivel de capacidad de prueba.

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

MVC

MVC son las siglas de Model-View-Controller. El controlador es responsable de crear modelos y renderizar vistas con modelos vinculantes.

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

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 varias vistas en el mismo controlador.

Respondido 01 Abr '20, 04:04

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.