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

49

Eu li por três dias sobre o Model-View-Controller (MVC ) e Model-View-Presenter (MVP) Padrões E há uma questão que me incomoda muito. Por que os designers de software inventaram o MVP, quando já existia 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 resolver?

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

Em um dos artigos que li, foi dito:

Now onto Model View Presenter, which was a response to the inadequacies of the MVC pattern when applied to modern component based graphical user interfaces. In modern GUI systems, GUI components themselves handle user input such as mouse movements and clicks, rather than some central controller.

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 sozinhos? E o que exatamente "manejar por si" significa?

    
por Victor 14.12.2016 / 16:37
fonte

2 respostas

62

O MVC é conceitualmente elegante:

  • a entrada do usuário é manipulada pelo controlador
  • o controlador atualiza o modelo
  • o modelo atualiza a visualização / interface do 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 tornam o sistema difícil de testar e de manter.

A arquitetura MVP substitui o controlador por um apresentador, que medeia entre a visã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 exibição para o apresentador.

  • A interface do usuário pode ser testada na 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 de forma independente.

Mas também existem algumas desvantagens nessa abordagem:

  • Requer mais esforço.
  • O apresentador pode facilmente se transformar em uma "classe de deus" inatingí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 muito.
por 14.12.2016 / 17:15
fonte
6

No MVP, o apresentador substitui o controlador do MVC. A diferença entre os dois é que o apresentador manipula diretamente a visão. Ele é projetado para estruturas de interface do usuário que são principalmente orientadas a eventos (como o Windows Forms) sem suporte pesado para vinculação de dados rich que emprestaria ao padrão MVVM (como o WPF). Caso contrário, muito da lógica para gerenciar o estado de exibição e atualizar o modelo de suporte residiria na própria visão.

    
por 14.12.2016 / 17:48
fonte