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.