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

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

¿Qué problemas 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 tenía una respuesta clara a mis preguntas.

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

Ahora en Model View Presenter, que fue una respuesta a las deficiencias 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 del mouse y los clics, en lugar de un controlador central.

Entonces, no puedo entender, pero ¿puede ser de otra manera, de modo que los componentes de la GUI no manejen la entrada del usuario por sí mismos? ¿Y qué significa exactamente "manejar por sí mismos"?

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á lógica significativa (como controladores de eventos para acciones de usuario). En conjunto, estas propiedades hacen que el sistema sea difícil de probar y difícil 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 en términos de 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.

• Dado que la interfaz de usuario está aislada de la lógica de la aplicación, ambas se pueden desarrollar de forma independiente.

Pero también hay algunos inconvenientes en este enfoque:

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

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 se basan principalmente en eventos (como Windows Forms) sin un gran soporte para 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.