Jump to content

Recommended Posts

Posted

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?

Posted

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.

  • 2 weeks later...
Posted

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.

Posted

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

Posted

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! 🙂

Posted

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

Posted

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).

Posted

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.