[Resolvido] MVP

[pistolsnguns]

Alguém me pode ajudar a descrever e como funciona o presenter no modelo arquitetônico MVP?

Obrigado

[Rui Carlos]

Alguns links:

https://www.portugal-a-programar.pt/topic/50373-model-view-presenter/

http://msdn.microsoft.com/en-us/library/ff647543.aspx

http://msdn.microsoft.com/en-us/library/ff648280.aspx

http://www.martinfowler.com/eaaDev/uiArchs.html

http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/

https://developers.google.com/web-toolkit/articles/mvp-architecture

[TomeVidal]

Boas tardes!

Não estou a perceber 😕

Então o MVController e o MVPresenter tem praticamente a mesma função, pelo que entendi o Presenter trabalha melhor para web2.0

Poderá se dizer que o MVP é a evolução do MVC?

[Rui Carlos]

Antes de mais, fica aqui um link para um discussão existente aqui no P@P, que me esqueci de referir:

https://www.portugal-a-programar.pt/topic/50373-model-view-presenter/

Do que tenho lido, o MVC e o MVP são efectivamente similares. Também fiquei com a ideia que a view no MVP tende a ser um pouco mais complexa que no MVC.

[rumbafum]

MVP e MVC têm o mesmo propósito, separação de UI da lógica para que seja possível testar esta última de forma conveniente. No entanto a forma como chegam a esse propósito é diferente.

No MVP, o Presenter é uma entidade intermediária entre a View e o Modelo. É responsável pela lógica e conhece tanto o modelo como a view.

Passive View e Supervising Controller são os "tipos" de implementação de MVP mais usadois diria. Passive View pressupõe que a View é bem tosca e não conhece nada do Modelo. Por isso para ter acesso a dados precisa que o Presenter lhe dê os mesmos.

Supervising Controller, a View conhece o Modelo e consegue obter dados para fazer bind de controlos sem necessidade do Presenter. Nestes casos o presenter é usado apenas para operações mais complexas, validações etc, e não directamente como middleman entre View e Modelo.

Em qualquer dos casos a View é que geralmente recebe a notificação de uma acção. Existe geralmente um Presenter para uma View, ou múltiplos Presenters para uma View.

MVP liga bem com ASP.NET WebForms e com Windows Forms também.

No MVC a acção é recebida pelo Controller e não pela View. O Controller processa esse pedido, trata dados, valida etc, e, geralmente devolve uma View como resposta.

Um controller pode ser partilhado entre várias Views. Aqui o Controller é mesmo o controlador de toda a acção o que não acontece no MVP

Isto tudo para dizer que no fim a escolha de MVP ou MVC deve ser de acordo com o desenho de aplicação que estamos a desenvolver. O objectivo da escolha de um destes padrões deve ser sempre a testagem da nossa lógica, uso de TDD etc.

[andrepintomp]

Boas!

Por acaso também ando a fazer um trabalho sobre o MVP, e com base em várias pesquisas a minha conclusão do MVP é esta:

"No MVP a View recebe da UI (User Interface) eventos e chama o Presenter quando este é preciso. Este é também responsável por actualizar a View com os novos dados que são ou foram gerados pelo Model."

Pode não estar completamente certa, mas penso que é uma abordagem próxima do que realmente é o MVP.

Posso estar enganado, mas acho que li em algum lado que o MVP era o sucessor do MVC, logo a sua evolução por assim dizer.

[rumbafum]

O MVP sucessor do MVC? Parece-me uma interpretação errada.

Quanto à definição de MVP vai de acordo com o que disse eu relação a uma implementação de MVP com uma View passiva. Mas atenção não tem de ser necessariamente assim o uso do padrão MVP. Existem muitas interpretações diferentes de MVP

[andrepintomp]

O MVP sucessor do MVC? Parece-me uma interpretação errada.

Provavelmente interpretei mal alguns artigos que andei a ler. 😕

Então o MVP e MVC são, digamos, diferentes? Ou seja, quando eu afirmei que o MVP era sucessor do MVP. O MVP e o MVC apenas têm interpretações diferentes nenhum sucede ao outro?

Cumps! 🙂

[rumbafum]

Correcto

[andrepintomp]

Obrigado!

Assim sempre posso acertar as minhas ideias em relação ao MVP. Tentar fazer alguns programas com base no padrão MVP, deverá ser mais fácil para perceber as diferenças. 🙂

[Ana Lúcia Baptista]

Ola =) estive a ler este ponto e penso que tenho uma opiniao que é capaz de te ajudar, ao contrario do MVC que todos os componentes interagem entre si, no MVP, o Model nao interage diretamente com a View e estes estao interligados atraves do Presenter sendo este responsavel pela interaçao do utilizador com o software. mas posso mostrar uma imagem que ajuda a compreender melhor:

http://imm.io/ZJ9X

espero ter sido util =)

Cumprimentos,Ana Baptista

[Rui Carlos]

estive a ler este ponto e penso que tenho uma opiniao que é capaz de te ajudar, ao contrario do MVC que todos os componentes interagem entre si, no MVP, o Model nao interage diretamente com a View e estes estao interligados atraves do Presenter sendo este responsavel pela interaçao do utilizador com o software.

Acho que isso não é totalmente verdade, e depende da variante de MVP usada: http://msdn.microsoft.com/en-us/library/ff647543.aspx (ver o MVP Supervising Controller).

[Ana Lúcia Baptista]

Sim nao tinha reparado nesse pormenor, mas estava a falar numa generalidade. Obrigada por me teres feito alargar os meus conhecimentos Rui Carlos =)

Cumprimentos, Ana Baptista

[Ana Lúcia Baptista]

Ja agora esta aqui um artigo que fala sobre estes topicos: http://www.c-sharpcorner.com/uploadfile/john_charles/model-view-presenter-mvp-design-pattern-and-data-binding/

Deste artigo tirei a conclusao que em MVP a camada Presenter assume a função de mediadora (executada pelo Controller em MVC). Além disso, a View é responsável por manipular os eventos UI, que era o trabalho da Controller. Eventualmente, a Model torna-se estritamente um modelo de domínio.

Cumprimentos, Ana Baptista