quarta-feira, 16 de dezembro de 2009

MVC x MVP: Resumo

No artigo Considerações Históricas sobre o padrão MVC, tradução de "MVC (Model View Controller) Design Pattern", você encontra uma série de 4 posts explicando as origens do MVC e suas variações, mostrando também como as interações entre Modelo, View e Controller são reorganizadas dando origem ao padrão MVP. Em resumo:

O MVC surgiu no início dos anos 80 e inspirou muitas frameworks na época. Cada elemento na tela possuia dois componentes: uma view, responsável pela sua exibição, e um controller, responsável por interpretar os eventos disparados pelos usuários. O controller comandava o modelo, que podia enviar notificações (indiretas) para a view poder se atualizar.

Para evitar o alto acoplamento entre o modelo e a View, surgiu o Application Model MVC, ou AM-MVC. Basicamente era uma camada intermediária, que permitia blindar melhor o modelo com relação à camada de apresentação (view e controllers).

Com o surgimento de novas tecnologias nos anos 90, o papel do controller caiu em desuso, pois os próprios widgets da view passaram a ter meios melhores de lidar com os eventos realizados pelos usuários. Além disso, em alguns casos, era conveniente o Modelo, ou o AM, poderem alterar diretamente a view, sem a necessidade de mecanismos indiretos.

Neste cenário, a IBM propôs o MVP, uma variação do MVC que seria mais adequada. Os adeptos do Smalltalk simplificaram o modelo da IBM e utilizaram no Smalltalk/Dolphin. No MVP, as responsabilidades que eram do Controller são redistribuídas entre a View e o Presenter. A View se encarrega de lidar com as entradas dos usuários, enquanto o Presenter se encarrega de interagir com o Modelo. Além disso, o Application Model do AM-MVC é substituído pelo Presenter, a quem é dado o direito de interagir diretamente com a View.

Martin Fowler catalogou o MVP na forma de dois padrões distintos:

  • Supervising Presenter: nesta forma, o presenter interpreta os eventos da View e comanda o modelo, alterando seu estado. Para atualizar sua exibição na tela de modo a refletir o novo estado do modelo, a view pode interagir diretamente com objetos do modelo, e obter os dados necessários. O modelo até pode se comunicar com a view, porém indiretamente, através de eventos, segundo o padrão Observer Synchronization.
  • Passive View: nesta forma, a view e o modelo são totalmente desacoplados, e todas as interações são realizadas por meio do Presenter. É uma abordagem que favorece o teste da aplicação, pois facilita o uso de mock views.

No novo milênio, o MVC ressurgiu com força total, quase um dogma em aplicações Web. De tão usado, seus conceitos acabaram se tornando difusos, às vezes mal interpretados, e confundidos com Arquitetura em Camadas. Leia MVC versus Camadas para entender melhor a diferença.

Uma limitação do MVC em aplicações web é a dificuldade de testar a camada de apresentação (view e controllers). O MVP parece mais adequado nestes casos, e seu uso tem sido encorajado em aplicações GWT (Google Web Toolkit).

Para concluir, a grande diferença entre MVC e MVP é a forma como o Modelo, a View e o Controller interagem, de modo a prover uma solução mais adequada, de acordo com a tecnologia utilizada e os objetivos desejados. Uma comparação mais detalhada entre o AM-MVC e o MVP/Passive view pode ser encontrada no artigo Do MVC para o MVP.

Nenhum comentário:

Postar um comentário