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


Al mirar más allá de la RAD (arrastrar y soltar) la forma de construir interfaces de usuario que muchas herramientas le alientan es probable que encuentre tres patrones de diseño llamados Modelo-Vista-Controlador, Modelo-Vista-Presentador 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?

1834
2017-08-05 10:06


origen


Respuestas:


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. Usted puede descubre más 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 de 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ón patró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. Este patrón es un candidato muy fuerte para su uso en aplicaciones WPF y también se llama Model-View-ViewModel.

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 (antiguo Prism) sobre Patrones de presentación separados


1796
2017-08-05 10:21



Publiqué 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 de MVP

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

Patrón MVC

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

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


384
2017-07-06 22:18



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

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



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

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP es no necesariamente un escenario donde View 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 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? Lo único real el patrón permanece como MVC, el resto son solo sabores diferentes de él.

Considerar esta artículo muy interesante 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.


148
2017-08-06 22:51



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.


90
2017-12-20 02:10



enter image description here

MVC (Controlador de vista de modelo)

La entrada se dirige al controlador primero, no a la vista. Esa entrada podría provenir de un usuario que interactúa con una página, pero también podría ser desde simplemente ingresar una url específica en un navegador. En cualquier caso, es un controlador que se interconecta con para iniciar alguna funcionalidad. Hay una relación muchos a uno entre el Controlador y la Vista. Esto se debe a que un solo controlador puede seleccionar diferentes vistas para representar en función de la operación que se está ejecutando. Tenga en cuenta la flecha de un sentido de Controller a View. Esto se debe a que View no tiene ningún conocimiento o referencia al controlador. El Controlador devuelve el Modelo, por lo que existe conocimiento entre la Vista y el Modelo esperado que se pasa a él, pero no el Controlador que lo está ejecutando.

MVP (Presentador de vista de modelo)

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

Para más Referencia


62
2017-08-05 10:22