¿Cuáles son las mejoras de MVP sobre MVC?

Question

¿Cuáles son las mejoras de MVP sobre MVC?

#1 de amon (62 votos)
#2 de Michael Brown (6 votos)

49

He leído durante tres días sobre el Model-View-Controller (MVC) ) y Model-View-Presenter (MVP) patrones. Y hay una pregunta que me molesta mucho. ¿Por qué los diseñadores de software inventaron MVP, cuando ya existía un MVC?

¿A qué problemas se enfrentaron, que MVC no resolvió (o resolvió mal), pero MVP puede resolver? ¿Qué problemas pretende resolver MVP?

He leído muchos artículos sobre la historia y la explicación de MVP, o sobre las diferencias entre MVC y MVP, pero ninguno tuvo una respuesta clara a mis preguntas.

En uno de los artículos que leí, se dijo:

Ahora en Model View Presenter, que fue una respuesta a las insuficiencias del patrón MVC cuando se aplicó a las interfaces gráficas de usuario modernas basadas en componentes. En los sistemas GUI modernos, los componentes de la GUI manejan la entrada del usuario, como los movimientos y clics del mouse, en lugar de un controlador central.

Por lo tanto, no puedo entenderlo, pero ¿puede realmente ser de otra manera, de manera que los componentes de la GUI no manejen la entrada del usuario por sí mismos? ¿Y qué significa exactamente "manejar por sí mismos"?

design design-patterns mvc mvp

pregunta Victor 14.12.2016 - 16:37

2 respuestas

Lea otras preguntas en las etiquetas design design-patterns mvc mvp

Entity Framework con sistemas grandes: ¿cómo dividir los modelos? ¿Es legal recrear / abrir un programa que usted haya codificado previamente para otra compañía?

score 62 · Answer 1

MVC es conceptualmente elegante:

la entrada del usuario es manejada por el controlador
el controlador actualiza el modelo
el modelo actualiza la vista / interfaz de usuario

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Sin embargo: el flujo de datos y eventos en MVC es circular. Y la vista a menudo contendrá una lógica significativa (como los controladores de eventos para las acciones del usuario). Juntas, estas propiedades hacen que el sistema sea difícil de probar y de mantener.

La arquitectura MVP reemplaza el controlador con un presentador, que media entre la vista y el modelo. Esto linealiza el sistema:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Esto tiene las siguientes ventajas:

La lógica (como los controladores de eventos y el estado de la interfaz de usuario) se puede mover de la vista al presentador.
La interfaz de usuario se puede probar por unidad en términos del presentador, ya que describe el estado de la interfaz de usuario. Dentro de la prueba de la unidad, reemplazamos la vista con un controlador de prueba que realiza llamadas al presentador.
Como la interfaz de usuario está aislada de la lógica de la aplicación, ambas pueden desarrollarse de forma independiente.

Pero también hay algunos inconvenientes en este enfoque:

Requiere más esfuerzo.
El presentador puede mutar fácilmente en una "clase de dios" que no se puede mantener.
La aplicación no tiene un solo eje de MVP, sino varios ejes: uno para cada pantalla / ventana / panel en la interfaz de usuario. Esto puede simplificar su arquitectura o complicarla horriblemente.

score 6 · Answer 2

En MVP, el presentador reemplaza el controlador de MVC. La diferencia entre los dos es que el presentador manipula directamente la vista. Está diseñado para marcos de UI que son principalmente impulsados por eventos (como los formularios de Windows) sin soporte pesado para el enlace de datos enriquecido que se prestaría al patrón MVVM (como WPF). De lo contrario, gran parte de la lógica para administrar el estado de la vista y actualizar el modelo de respaldo estaría en la vista misma.