Model View-Presenter

Question

Olá Pessoal,

Gostaria de iniciar uma discussão sobre o design pattern view-presenter. Quero coletar feedback de quem já está usando esse modelo.

 

Pessoalmente eu acho muito bom pois organiza o código ao levar para a presenter a lógica para responder aos eventos na UI e facilita em MUITO a tarefa de testar, já que é possível criar mock objects e realizar os testes.

Além de fornecer certa independência, pois caso seja necessário alterar um componente de UI não é preciso alterar a presenter.

Aguardo mais comentários

 

[]s

Answer 1

Caro Daniel: 

 

O que voce diz é resultado de que normalmente muitos codigos gerenciam eventos e logica numa mesma classe de um formulario, o que ha torna inviavelmente complexa de manter e provar. Umas das solucoes para este problema é seperar os concerns de presentar os aspectos visuais, o dominio e os de tratar ou responder aos eventos. En resumo o Presenter tem a responsa de atualizar o dominio qdo pinta um evento na vista, mas em outra mao, tambem atualiza a vista qdo o dominio indica que foi modificado!

 

Como o modelo nao conhece o Presenter, ele sempre dispara un evento para informar sua alteracao. Já o Presenter, através do modelo flexivel de publicao e subscricao, subcreve e publica todos os eventos necesarios. (CAB atraves dos EventBrokers ajuda pacas nesta tarefa).

 

CAB (Composite Application Software factory), WCSF (Web Application Software factory) promovem esse tipo de desenho pelos fatores resultantes desse tipo de arquitetura: facil manutencao, facil de provar e facil de alterar os componentes da UI. Otras vantagens é que o

 

Outro detalhe que nao podemos esquecer é que a "injecao de dependencia" tem um rol neste "modelo".

 

Utilizei esse tipo de arquitetura em alguns projetos e me parece interessante, porém como sempre digo, utilizar o CAB de verdade, a full, 200 por hora, tem seu custo pois fazer um grupo de desenvolvedores a trabalhar bem vai custar alguns meses para fazer de 0 a 100 Km/h. Entao vale sempre ponderar o custo inicial e a vantagem final de ter um desenvolvimento baseado em TDD, o que possibilita a utilizacao de implementacoes fakes-mock pois o presenter vai estar apontando somente interfaces.

 

 

Abs

-Fernando Costa

http://sushinetcode.blogdrive.com

 

 

 

 

 

  

Answer 2

Oi Fernando,

 

Como foi o resultado final dos projetos utilizando MVP??

Com todas aquelas chamadas até a presenter eu tenho com certeza mais overhead. Isso chega a causar problemas de performance nas aplicações? Pq se eu fizesse direto no code-behind com certeza teria menos trabalho para a aplicação, porém o código nao ficaria tão organizado e testavel.

 

[]s

 

Answer 3

Como lhe disse o custo de implementar o MVP pode ser alto a curto prazo, porém os beneficios sao inumero.
Aqui onde trabalho, temos implementacoes de MVP em projetos de todos os portes e tamanho de cliente, por isso deixo minha recomendacao é que sempre deve-se ter em conta que dependendo do tamanho do projeto e da quantidade de codigo a ser escrita vale a pena "echar un ojo" nas vistas que tem grande entrada de informacao, pois essas sim podem ser as excecoes e causas de seu overhead.
O fato de voce fazer no code-behind de fato nao lhe indica o que é menos trabalho para sua aplicacao, tudo depende de como esta sendo implementado a solucao anterior, assim como a implementacao de MVP, nao pode ser considerada a causa de seus problemas de rendimento. Na mesma ideia, utilizar code-behind nao garante que sua arquitetura seja MVC de verdade.
Como diz o Kesman, "uma coisa é uma coisa, outra coisa é outra coisa"

 

Abs

-Fernando Costa
http://sushinetcode.blogdrive.com


 

Answer 4

Senhores,

 

Tive a oportunidade de trabalhar em 2 projetos grandes (um com um prazo apertado e o outro com o prazo longo) usando essa arquitetura de desenvolvimento.

 

E em ambos os projetos entregamos atrasado (mas, não por falta de conhecimento técnico, e sim por precpitação em querer implementar um modelo de arquitetura que não foi testado).

 

Concluimos que a utilização desse pattern é muito interessante devido a uma série de vantagens que ja foram citadas anteriormente, porém é muito custoso devido a uma série de fatores, dentro deles, o principais são:

 

Para cada .aspx é necessário criar uma interface equivalente e cada .aspx deve herdar essa interface (Imagine um contexto de uma aplicação que possui mais de 100 páginas dinamicas).

Cada view precisa de um presenter, ou 1 presenter tem várias views associadas a ele (mesmo contexto acima).

 

Isso é muito estressante !

 

Concordo que, o resultado, é uma aplicação hibrida, que irá funcionar tanto em windows forms, quanto em web ou wpf, mas o trabalho que se tem para criar essa arquitetura é muito grande.

 

Mas, eu sou totalmente adepto a esta arquitetura, tão adepto, que criei uma biblioteca para trabalhar com esse pattern de forma simples e transparente, sem ter a necessidade de ficar criando um presenter para cada view e uma view para cada aspx. Hoje, eu tenho um presenter/controller por entidade e uma view generica com Get<T> e Set<T> gerencis (tipados) ..

 

Facilitou muito!

 

Abraços

Filipe

 

FernandoCosta_Brasil wrote:

Como lhe disse o custo de implementar o MVP pode ser alto a curto prazo, porém os beneficios sao inumero. Aqui onde trabalho, temos implementacoes de MVP em projetos de todos os portes e tamanho de cliente, por isso deixo minha recomendacao é que sempre deve-se ter em conta que dependendo do tamanho do projeto e da quantidade de codigo a ser escrita vale a pena "echar un ojo" nas vistas que tem grande entrada de informacao, pois essas sim podem ser as excecoes e causas de seu overhead. O fato de voce fazer no code-behind de fato nao lhe indica o que é menos trabalho para sua aplicacao, tudo depende de como esta sendo implementado a solucao anterior, assim como a implementacao de MVP, nao pode ser considerada a causa de seus problemas de rendimento. Na mesma ideia, utilizar code-behind nao garante que sua arquitetura seja MVC de verdade. Como diz o Kesman, "uma coisa é uma coisa, outra coisa é outra coisa"   Abs -Fernando Costa http://sushinetcode.blogdrive.com

Answer 5

A grande dificuldade está em desassociar o Controller/Presenter da view na maioria das aplicações web (event-driven). IMHO, trabalhar numa camada de aplicação é mais produtivo e gera menos percalços durante a implementação.

[]s

Answer 6

Ola Daniel também ja tive oportunidade de trabalhar com esse pattern, como o nosso amigo Filipe postou o extressante é ter que criar Interfaces pra todo lado, com uma customização da pra tirar esse sacrificio, no entanto hoje dependendo de que tipo de projeto estamos falando e de que responsabilidades ele terá é bom demais usa-lo, principamente na questão outros dispositivos..