Quais são as melhorias do MVP sobre o MVC?

Eu li por três dias sobre os padrões Model-View-Controller (MVC) e Model-View-Presenter (MVP) . E há uma pergunta que me incomoda muito. Por que os designers de software inventaram o MVP, quando já havia um MVC?

Quais problemas eles enfrentaram, que o MVC não resolveu (ou resolveu mal), mas o MVP pode resolver? Quais problemas o MVP pretende solucionar?

Eu li muitos artigos sobre o histórico e a explicação do MVP, ou sobre as diferenças entre o MVC e o MVP, mas nenhum teve uma resposta clara para minhas perguntas.

Em um dos artigos que li, foi dito:

Agora no Model View Presenter, que era uma resposta às inadequações do padrão MVC quando aplicado a interfaces gráficas de usuário modernas baseadas em componentes. Nos sistemas modernos da GUI, os próprios componentes da GUI tratam da entrada do usuário, como movimentos e cliques do mouse, em vez de algum controlador central.

Então, eu não consigo entender, mas pode ser de outra maneira, de modo que os componentes da GUI não lidem com a entrada do usuário por si mesmos? E o que exatamente "lidar com eles" significa?

O MVC é conceitualmente elegante:

• a entrada do usuário é tratada pelo controlador
• o controlador atualiza o modelo
• o modelo atualiza a visualização / interface com o usuário

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

No entanto: o fluxo de dados e eventos no MVC é circular. E a exibição geralmente contém lógica significativa (como manipuladores de eventos para ações do usuário). Juntas, essas propriedades dificultam o teste e a manutenção do sistema.

A arquitetura MVP substitui o controlador por um apresentador, que medeia entre a visualização e o modelo. Isso lineariza o sistema:

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

Isso tem as seguintes vantagens:

• A lógica (como manipuladores de eventos e estado da interface do usuário) pode ser movida da visualização para o apresentador.

• A interface do usuário pode ser testada em unidade em termos do apresentador, pois descreve o estado da interface do usuário. Dentro do teste de unidade, substituímos a visualização por um driver de teste que faz chamadas para o apresentador.

• Como a interface do usuário é isolada da lógica do aplicativo, ambas podem ser desenvolvidas independentemente.

Mas também existem algumas desvantagens nessa abordagem:

• Isso requer mais esforço.
• O apresentador pode facilmente transformar-se em uma "classe divina" insustentável.
• O aplicativo não possui um único eixo MVP, mas vários eixos: um para cada tela / janela / painel na interface do usuário. Isso pode simplificar sua arquitetura ou complicá-la terrivelmente.

No MVP, o Presenter substitui o Controller do MVC. A diferença entre os dois é que o Presenter manipula diretamente a Visualização. Ele foi projetado para estruturas de interface do usuário que são principalmente orientadas a eventos (como Windows Forms) sem suporte pesado para ligação de dados sofisticada que emprestaria ao padrão MVVM (como WPF). Caso contrário, grande parte da lógica para gerenciar o estado da exibição e atualizar o modelo de backup estaria na própria exibição.