Não podemos dizer que o padrão MVP (Model-View-Presenter) é recente, mesmo por que foi proposto no início dos anos noventa. Mas ainda assim parece novo para muitos desenvolvedores, que ainda não se familiarizaram com ele.

O padrão MVP é derivado do conhecido padrão MVC, onde os componentes Model, View e Controller se comunicam. Em uma breve descrição do padrão MVC podemos dizer que a View representa a visualização propriamente dita, sendo representada por um Web Form, Windows Form ou outra forma de interface com o usuário. O Model é responsável por tratar os dados e os comportamentos da aplicação, e o Controller contém a lógica necessária para conectar o Model à View, convertendo as ações da View em eventos que o Model é capaz de tratar.

O motivo pela qual descrevi brevemente o padrão MVC, é que ele inspirou e serve de base para o padrão MVP, onde o Presenter assume o lugar do Controller. Mas por qual o objetivo ? 

No padrão MVP a View não se comunica com o Model, chamamos esta abordagem de Passive View. Neste caso, como o nome sugere, a View é completamente passiva e deixa para o Presenter o papel de tratar suas ações e dizer quando e como ela deve ser atualizada.

A organização proposta pela abordagem Passive View é excelente, mas implica em maior complexidade para tarefas simples como preencher controles (Data Binding). E é por este motivo que existe ainda uma segunda abordagem no padrão MVP, o Supervising Controller, onde a única diferença é permitir que a View acesse o Model, mas somente para realizar Data Bindings.

Diagrama das duas abordagens distintas:



Explicado o funcionamento do padrão, gostaria de demonstrá-lo na prática (abordagem Passive View), utilizando um simples exemplo em ASP.NET.

Começaremos pela View, um simples WebForm contendo um TextBox para informarmos o valor, um botão para disparar a ação e uma Label para exibir o resultado:

Para que o Presenter seja capaz de manipular a View ele deve possuir uma referência a ela, e para tanto utilizaremos uma interface:


Code-Behind da View, implementando nossa interface:


Note que a View delega a execução das ações (eventos) ao Presenter.

Estando definida a View, vamos ao Model, que em nosso exemplo possui uma lógica simples de receber um valor numérico e devolver um comentário equivalente:


E finalmente o tão esperado Presenter, que conhece muito bem a View e o Model, e irá conectá-los:


Conforme descrito o Presenter recebe as ações da View, realiza os tratamentos necessários junto ao Model, e termina atualizando a View.

Para simplificar o exemplo ignorei as validações, mas lembrem-se delas em suas implementações.

Abraços,
Daniel Cheida de Oliveira