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?

— Vencedor
fonte

Duplicação de stackoverflow.com/questions/2056/…

— qwerty_so 14/12/16

Eu acho que é apenas "As Novas Roupas do Imperador", uma nova palavra da moda da Mickeysoft.

— qwerty_so

Victor, você tem uma pergunta específica diferente de "por que existem dois padrões diferentes?" Existem dois padrões diferentes porque eles resolvem o mesmo problema de duas maneiras um tanto diferentes. Se ajudar, o Modelo e a Visualização são essencialmente os mesmos nos dois padrões. Concentre-se nas diferenças entre um Controlador e um Apresentador. Você pode encontrar mais ajuda aqui: linkedin.com/pulse/…

— Robert Harvey

"Eu li por três dias sobre os padrões MVC e MVP". Caramba. Sugiro que você tome um banho quente relaxante ou pule algumas pedras em um lago cheio de patos ou algo assim. Na ausência de qualquer aplicação prática, esse tipo de leitura pode realmente derreter seu cérebro!

— user1172763

A maneira como você obtém o tipo de resposta desejada é criando algo usando esses padrões. Então você será iluminado.

— Robert Harvey

Respostas:

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.

— amon
fonte

Boa resposta, mas o MVC atual geralmente não usa muito (se houver) os manipuladores de eventos, exceto talvez a validação de formulário local, e eu não considero esses eventos parte do MVC. É por isso que temos MVP e MVVM. O MVC é essencialmente do lado do servidor.

— Robert Harvey

@ amon, obrigado pela sua resposta, isso diz muitas coisas para mim. E você menciona que ter vários eixos no aplicativo pode simplificar a arquitetura. Eu conheço essa ideia em muitos artigos, e foi mencionado, como um dos principais motivos para inventar o MVP, porque o MVC não corresponde a requisitos complexos de GUIs. Ou seja, quais requisitos o MVP corresponde e como os soluciona? Desculpe por ser tão persistente, mas eu realmente quero entender bem.

— 213 Victor Victor

@ Victor Não existe um padrão melhor, mas as vantagens e desvantagens são diferentes. O MVC pode corresponder a requisitos complicados. Em termos de arquitetura, o MVP impõe um relacionamento 1: 1 entre visualizações e apresentadores: cada visualização possui seu próprio apresentador, cada apresentador é conectado a uma visualização. No MVC, existe um relacionamento n: m: uma visualização pode enviar entrada do usuário para vários controladores diferentes e um controlador pode receber entrada de várias visualizações. Isso é mais flexível, mas também mais caótico - não há um “eixo” claro no MVC.

— amon

@ Victor Eu não tenho muita experiência com GUIs, então provavelmente há muita coisa que eu não mencionei. A última GUI que fiz foi uma bagunça absoluta, porque não conhecia o MVP naquele momento - um fluxo de dados e controle linearizado teria sido uma grande melhoria.

— amon

@RobertHarvey Eu diria que o que a web chama de "MVC" nunca foi realmente "MVC" pela definição original. Quem seqüestrou o acrônimo deve ser atingido na cabeça por escolher um termo carregado e confundir todo mundo.

— jpmc26

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.

— Michael Brown
fonte