O que são MVP e MVC e qual é a diferença?

2133

Ao olhar para além da maneira RAD (arrastar e soltar e configurar) de criar interfaces de usuário, muitas ferramentas incentivam a probabilidade de você encontrar três padrões de design chamados Model-View-Controller , Model-View-Presenter e Model-View-ViewModel . Minha pergunta tem três partes:

  1. Quais problemas esses padrões abordam?
  2. Como eles são semelhantes?
  3. Como eles são diferentes?
Mike Minutillo
fonte
4
mvc.givan.se/#mvp
givanse
2
IDK, mas supostamente para o MVC original, era para ser usado no pequeno. Cada botão, etiqueta etc. tinha sua própria visão e objeto de controlador, ou pelo menos é o que o tio Bob afirma. Eu acho que ele estava falando sobre Smalltalk. Veja as palestras dele no YouTube, elas são fascinantes.
still_dreaming_1
MVP adiciona uma camada extra de engano, dividindo o View-Controller em uma visão e um apresentador ...
the_prole
2
A principal diferença é que, no MVC, o Controlador não passa nenhum dado do Modelo para a Visualização. Ele apenas notifica a View para obter os dados do próprio Modelo. No entanto, no MVP, não há conexão entre a View e o Model. O próprio apresentador obtém todos os dados necessários do modelo e os passa para a exibição para mostrar. Mais a este, juntamente com uma amostra android em todos os padrões de arquitetura está aqui: digigene.com/category/android/android-architecture
Ali Nem
Eles são chamados de padrões arquiteturais, não padrões de design . Se você quiser saber a diferença, verifique isto
Hasan El-Hefnawy

Respostas:

1997

Model-View-Presenter

No MVP , o Presenter contém a lógica comercial da interface do usuário para a exibição. Todas as chamadas do View são delegadas diretamente ao Presenter. O apresentador também é dissociado diretamente da exibição e conversa com ele por meio de uma interface. Isso é para permitir zombar da exibição em um teste de unidade. Um atributo comum do MVP é que deve haver muitos despachos bidirecionais. Por exemplo, quando alguém clica no botão "Salvar", o manipulador de eventos delega ao método "OnSave" do Presenter. Após a conclusão do salvamento, o Apresentador retornará a Visualização através de sua interface, para que a Visualização possa exibir que a gravação foi concluída.

O MVP tende a ser um padrão muito natural para obter apresentações separadas em Web Forms. O motivo é que o modo de exibição é sempre criado primeiro pelo tempo de execução do ASP.NET. Você pode descobrir mais sobre as duas variantes .

Duas variações primárias

Visão passiva: a visão é o mais burra possível e contém lógica quase nula. O apresentador é um intermediário que fala com a View e o Model. A Vista e o Modelo são completamente protegidos um do outro. O Modelo pode gerar eventos, mas o Apresentador os assina para atualizar a Visualização. Na Visualização Passiva, não há ligação direta aos dados. Em vez disso, a Visualização expõe as propriedades do setter que o Presenter usa para definir os dados. Todo o estado é gerenciado no Presenter e não na View.

  • Pro: superfície máxima de testabilidade; separação limpa da Vista e do Modelo
  • Con: mais trabalho (por exemplo, todas as propriedades do setter), como você mesmo faz com todos os dados.

Controlador de supervisão: o apresentador lida com gestos do usuário. A Visualização se liga ao Modelo diretamente através da ligação de dados. Nesse caso, é tarefa do apresentador transmitir o modelo para a visualização para que ele possa se vincular a ele. O apresentador também conterá lógica para gestos, como pressionar um botão, navegação etc.

  • Pro: aproveitando a ligação de dados, a quantidade de código é reduzida.
  • Contras: há menos superfície testável (por causa da ligação de dados) e há menos encapsulamento no View, pois ele fala diretamente com o Model.

Model-View-Controller

No MVC , o Controlador é responsável por determinar qual Visualização exibir em resposta a qualquer ação, incluindo quando o aplicativo é carregado. Isso difere do MVP, onde as ações são roteadas pela tela para o apresentador. No MVC, toda ação na Visualização se correlaciona com uma chamada para um Controller junto com uma ação. Na web, cada ação envolve uma chamada para uma URL do outro lado da qual existe um Controller que responde. Depois que o Controlador concluir seu processamento, ele retornará a Visualização correta. A sequência continua dessa maneira ao longo da vida do aplicativo:

    Ação na exibição
        -> Chamada ao controlador
        -> Lógica do Controlador
        -> Controller retorna a View.

Uma outra grande diferença sobre o MVC é que o View não se liga diretamente ao modelo. A visualização é renderizada e é completamente sem estado. Nas implementações do MVC, o View geralmente não possui lógica no código por trás. Isso é contrário ao MVP, onde é absolutamente necessário, porque, se o View não delegar ao Presenter, ele nunca será chamado.

Modelo de Apresentação

Outro padrão a ser observado é o modelo de apresentaçãopadronizar. Nesse padrão, não há apresentador. Em vez disso, o modo de exibição vincula diretamente a um modelo de apresentação. O modelo de apresentação é um modelo criado especificamente para a visualização. Isso significa que este modelo pode expor propriedades que nunca se colocaria em um modelo de domínio, pois isso seria uma violação da separação de preocupações. Nesse caso, o modelo de apresentação é vinculado ao modelo de domínio e pode se inscrever em eventos provenientes desse modelo. O modo de exibição se inscreve em eventos provenientes do modelo de apresentação e se atualiza de acordo. O modelo de apresentação pode expor comandos que a exibição usa para chamar ações. A vantagem dessa abordagem é que você pode essencialmente remover completamente o code-behind, pois o PM encapsula completamente todo o comportamento da exibição.Model-View-ViewModel .

Há um artigo do MSDN sobre o Modelo de Apresentação e uma seção no Guia de Aplicação Composta do WPF (antigo Prism) sobre Padrões de Apresentação Separados

Glenn Block
fonte
27
Você pode esclarecer esta frase? Isso difere do MVP, onde as ações são roteadas pela tela para o apresentador. No MVC, toda ação na Visualização se correlaciona com uma chamada para um Controller junto com uma ação. Para mim, parece a mesma coisa, mas tenho certeza que você está descrevendo algo diferente.
Panzercrisis
16
@ Panzercrisis Não tenho certeza se é isso que o autor quis dizer, mas é isso que acho que eles estavam tentando dizer. Como esta resposta - stackoverflow.com/a/2068/74556 menciona, no MVC, os métodos do controlador são baseados em comportamentos - em outras palavras, você pode mapear várias visualizações (mas o mesmo comportamento) para um único controlador. No MVP, o apresentador é acoplado mais perto da visualização e geralmente resulta em um mapeamento mais próximo de um para um, ou seja, uma ação de visualização é mapeada para o método do apresentador correspondente. Você normalmente não mapeia as ações de outra visão para o método de outro apresentador (de outra visão).
Dustin Kendall
2
Observe que isso MVC geralmente é usado por estruturas da Web como Laravel, onde as solicitações de URL recebidas (talvez feitas pelos usuários) são tratadas pelo Controllere o HTML gerado pelo Viewé enviado ao cliente - portanto, isso Viewfaz parte do back - end e do o usuário nunca pode acessá-lo diretamente e, se você experimentar qualquer outro lugar, considere isso como uma extensão MVC (ou mesmo uma violação). @ Panzercrisis, difere de MVP(como o usado no AndroidSO), onde o actions route through the View to the Presenterusuário tem acesso direto ao View.
Top-Master
455

Essa é uma simplificação excessiva das muitas variantes desses padrões de design, mas é assim que eu gosto de pensar sobre as diferenças entre os dois.

MVC

MVC

MVP

insira a descrição da imagem aqui

Phyxx
fonte
10
Esta é uma ótima descrição do esquema, mostrando a abstração e o isolamento completo de qualquer GUI relacionada (exibir material) da API do apresentador. Um ponto secundário: um apresentador mestre pode ser usado onde existe apenas um apresentador, em vez de um por exibição, mas o seu diagrama é o mais limpo. Na IMO, a maior diferença entre o MVC / MVP é que o MVP tenta manter a visualização totalmente vazia de qualquer coisa que não seja a exibição do 'estado da visualização' atual (exibir dados), além de impedir a visualização de qualquer conhecimento dos objetos Modelo. Assim, as interfaces, que precisam estar lá, injetam esse estado.
4
Boa foto. Eu uso bastante o MVP, então gostaria de fazer um ponto. Na minha experiência, os apresentadores precisam conversar um com o outro com bastante frequência. O mesmo vale para os modelos (ou objetos de negócios). Devido a essas "linhas azuis" adicionais de comunicação que estariam na sua foto do MVP, os relacionamentos Modelo de Apresentador podem ficar bastante entrelaçados. Portanto, tenho a tendência de manter um relacionamento um-para-um apresentador-modelo versus um-para-muitos. Sim, requer alguns métodos delegados adicionais no modelo, mas reduz muitas dores de cabeça se a API do modelo mudar ou precisar de refatoração.
splungebob
3
O exemplo MVC está errado; existe um relacionamento 1: 1 estrito entre visualizações e controladores. Por definição, um controlador interpreta a entrada de gestos humanos para produzir eventos para o modelo e exibir para um único controle. Mais simplesmente, o MVC foi projetado para uso apenas com widgets individuais. Um widget, uma visão, um controle.
Samuel A. Falvo II
3
@ SamuelA.FalvoII nem sempre, há uma 1: Muitos entre os controladores e pontos de vista em ASP.NET MVC: stackoverflow.com/questions/1673301/...
StuperUser
4
@ SuperUser - Não tenho certeza do que eu estava pensando quando escrevi isso. Você está certo, é claro, e olhando para o que escrevi, tenho que me perguntar se tinha algum outro contexto em mente que não consegui articular. Obrigado pela correção.
Samuel A. Falvo II
421

Eu escrevi sobre isso há algum tempo, citando o excelente post de Todd Snyder sobre a diferença entre os dois :

Aqui estão as principais diferenças entre os padrões:

Padrão MVP

  • A vista é mais fracamente acoplada ao modelo. O apresentador é responsável por vincular o modelo à visualização.
  • Teste de unidade mais fácil porque a interação com a visualização é feita através de uma interface
  • Geralmente, visualize o mapa do apresentador um a um. Visualizações complexas podem ter vários apresentadores.

Padrão MVC

  • Controladores são baseados em comportamentos e podem ser compartilhados entre visualizações
  • Pode ser responsável por determinar qual visualização exibir

É a melhor explicação na web que eu poderia encontrar.

Jon Limjap
fonte
15
Eu não entendo como, na visão, pode ser acoplado mais ou menos ao modelo, quando, em ambos os casos, o ponto principal é dissociá-los completamente. Não estou sugerindo que você disse algo errado - apenas confuso quanto ao que você quer dizer.
Bill K
18
@pst: com o MVP é realmente 1 View = 1 Presenter. Com o MVC, o Controlador pode controlar várias visualizações. É isso mesmo. Com o modelo "guias", imagine que cada guia tenha seu próprio apresentador, em vez de ter um controlador para todas as guias.
precisa
4
Originalmente, existem dois tipos de controladores: aquele que você disse ser compartilhado em várias visualizações e aqueles que são específicos, principalmente para adaptar a interface do controlador compartilhado.
Acsor
1
@JonLimjap O que significa uma visualização de qualquer maneira? No contexto da programação do iOS, é uma tela? Isso torna o controlador do iOS mais parecido com MVP do que MVC? (Por outro lado, você também pode ter vários controladores iOS por tela)
huggie
2
A ilustração diagramática de MVC de Todd contradiz completamente a idéia de dissociar a View e o Model. Se você olhar para o diagrama, ele diz Model updates View (seta de Model to View). Em que universo é um sistema, onde o Modelo interage diretamente com a View, um dissociado ???
Ash
260

Aqui estão ilustrações que representam o fluxo de comunicação

insira a descrição da imagem aqui

insira a descrição da imagem aqui

Ashraf Bashir
fonte
44
Eu tenho uma pergunta sobre o diagrama MVC. Eu não entendo a parte em que a exibição sai para buscar dados. Eu acho que o controlador encaminhará para a exibição com os dados necessários.
Brian Rizo
54
Se um usuário clicar em um botão, como isso não está interagindo com a exibição? Eu me sinto como no MVC, o usuário interage com o ponto de vista mais do que o controlador
Jonathan
5
Sei que essa é uma resposta antiga - mas alguém poderia responder no ponto @ JonathanLeaders? Eu venho de um plano de fundo winforms, a menos que você tenha criado uma codificação muito exclusiva, quando você clica na interface do usuário / View obtém conhecimento desse clique antes de qualquer outra coisa. Pelo menos, tanto quanto eu sei?
Rob P.
6
@RobP. Eu acho que esses tipos de gráficos sempre tendem a ser muito complexos ou muito simples. Imo, o fluxo do gráfico MVP também é válido para um aplicativo MVC. Pode haver variações, dependendo dos recursos de idiomas (ligação de dados / observador), mas no final a idéia é separar a visualização dos dados / lógica do aplicativo.
Luca Fülbier 17/01/16
15
@ JonathanLeaders As pessoas têm coisas realmente diferentes em mente quando dizem "MVC". A pessoa que criou este gráfico provavelmente tinha em mente o MVC da Web clássico, em que a "entrada do usuário" são solicitações HTTP e "a exibição retornada ao usuário" é uma página HTML renderizada. Portanto, qualquer interação entre um usuário e uma exibição "não existe" da perspectiva de um autor do aplicativo clássico da Web MVC.
cubuspl42
170

O MVP não é necessariamente um cenário em que a View é responsável (veja o MVP da Taligent, por exemplo).
Acho lamentável que as pessoas ainda estejam pregando isso como um padrão (View in charge) em oposição a um anti-padrão, pois contradiz "É apenas uma view" (Programador Pragmático). "É apenas uma visão" afirma que a visão final mostrada ao usuário é uma preocupação secundária do aplicativo. O padrão MVP da Microsoft torna a reutilização do Views muito mais difícil e convenientemente dispensa o designer da Microsoft de incentivar más práticas.

Para ser perfeitamente franco, acho que as preocupações subjacentes ao MVC são verdadeiras para qualquer implementação do MVP e as diferenças são quase inteiramente semânticas. Desde que você esteja seguindo a separação de preocupações entre a visualização (que exibe os dados), o controlador (que inicializa e controla a interação do usuário) e o modelo (os dados e / ou serviços subjacentes)), então você está obtendo os benefícios do MVC . Se você está obtendo os benefícios, quem realmente se importa se seu padrão é MVC, MVP ou Supervising Controller? O único padrão real permanece como MVC, o resto são apenas sabores diferentes.

Considere este artigo altamente interessante que lista de forma abrangente várias dessas implementações diferentes. Você pode notar que eles estão basicamente fazendo a mesma coisa, mas um pouco diferente.

Pessoalmente, acho que MVP foi recentemente reintroduzido como um termo cativante para reduzir os argumentos entre fanáticos semânticos que argumentam se algo é realmente MVC ou não ou para justificar as ferramentas de desenvolvimento rápido de aplicativos da Microsofts. Nenhuma dessas razões em meus livros justifica sua existência como um padrão de design separado.

Quibblesome
fonte
28
Eu li várias respostas e blogs sobre as diferenças entre MVC / MVP / MVVM / etc '. De fato, quando você trabalha, é tudo a mesma coisa. Realmente não importa se você tem uma interface ou não, e se está usando um setter (ou qualquer outro recurso de idioma). Parece que a diferença entre esses padrões nasceu da diferença de implementações de várias estruturas, em vez de uma questão de conceito.
Michael
6
Eu não chamaria o MVP de anti-padrão , pois mais tarde no post "..o resto [incluindo MVP] são apenas sabores diferentes do [MVC] ..", o que implicaria que se o MVP fosse um anti-padrão, então foi MVC ... é apenas um sabor para a abordagem de uma estrutura diferente. (Agora, algumas específicas implementações MVP pode ser mais ou menos desejável do que algumas específicas implementações MVC para diferentes tarefas ...)
@Quibblsome: “Pessoalmente, acho que MVP foi recentemente reintroduzido como um termo cativante para reduzir os argumentos entre fanáticos semânticos que argumentam se algo é realmente MVC ou não […] Nenhuma dessas razões em meus livros justifica sua existência como um padrão de design separado ". . Difere o suficiente para torná-lo distinto. No MVP, a exibição pode ser algo que preencha uma interface predefinida (a exibição no MVP é um componente independente). No MVC, o Controller é feito para uma visão específica (se as aridades da relação fizerem alguém sentir que vale outro termo).
Hibou57
6
@ Hibou57, não há nada que impeça o MVC de referenciar a visualização como uma interface ou de criar um controlador genérico para várias visualizações diferentes.
Quibblesome
1
Samuel, por favor, esclareça o que você está falando. A menos que você esteja me contando a história da equipe que "inventou" o MVC, então eu sou incrivelmente dúbio sobre o seu texto. Se você está apenas falando sobre o WinForm, existem outras maneiras de fazer as coisas e eu criei projetos do WinForm nos quais as ligações de controle são gerenciadas pelo controlador, e não "controles individuais".
Quibblesome
110

MVP: a visualização está no comando.

A visualização, na maioria dos casos, cria seu apresentador. O apresentador irá interagir com o modelo e manipular a visualização por meio de uma interface. Às vezes, a exibição interage com o apresentador, geralmente através de alguma interface. Isso se resume à implementação; você deseja que a exibição chame métodos no apresentador ou deseja que a exibição tenha eventos que o apresentador escuta? Tudo se resume a isso: a visão conhece o apresentador. A exibição delega ao apresentador.

MVC: o controlador está no comando.

O controlador é criado ou acessado com base em algum evento / solicitação. O controlador cria a visualização apropriada e interage com o modelo para configurar ainda mais a visualização. Tudo se resume a: o controlador cria e gerencia a exibição; a vista é escrava do controlador. A vista não sabe sobre o controlador.

Brian Leahy
fonte
3
"O View não conhece o Controller." Eu acho que você quer dizer que a visão não tem contato diretamente com o modelo?
Lotus Notes
2
Essa visão nunca deve saber sobre o modelo em outra.
Brian Leahy
4
@Brian: “O View, na maioria dos casos, cria o Presenter.” . Eu vi principalmente o oposto, com o Presenter lançando o Model e o View. Bem, o View pode iniciar o Presenter também, mas esse ponto não é realmente o mais distinto. O que mais importa acontece mais tarde durante a vida.
Hibou57
2
Você pode editar sua resposta para explicar melhor: Como o View não sabe sobre o Controller, como são as ações do usuário, executadas nos elementos 'visuais' que o usuário vê na tela (ou seja, o View), comunicadas ao Controller ... #
580 Ash
77

insira a descrição da imagem aqui

MVC (Model View Controller)

A entrada é direcionada primeiro ao Controlador, não à visualização. Essa entrada pode ser proveniente de um usuário interagindo com uma página, mas também pode ser simplesmente inserindo um URL específico em um navegador. Em qualquer um dos casos, é um Controlador com interface para iniciar algumas funcionalidades. Há um relacionamento muitos-para-um entre o Controller e a View. Isso ocorre porque um único controlador pode selecionar diferentes visualizações a serem renderizadas com base na operação que está sendo executada. Observe a seta de sentido único de Controller para View. Isso ocorre porque o View não tem nenhum conhecimento ou referência ao controlador. O Controller repassa o Modelo, para que haja conhecimento entre a Visualização e o Modelo esperado que está sendo passado para ele, mas não o Controlador que o serve.

MVP (Model View Presenter)

A entrada começa com a exibição, não o apresentador. Há um mapeamento individual entre a View e o Presenter associado. A exibição contém uma referência ao apresentador. O Apresentador também está reagindo aos eventos que estão sendo acionados a partir da Visualização, para que esteja ciente da Visualização que está associada. O Presenter atualiza a Visualização com base nas ações solicitadas que ele executa no Modelo, mas a Visualização não reconhece o Modelo.

Para mais referência

AVI
fonte
Mas, no MVPpadrão, quando o aplicativo é carregado pela primeira vez, o apresentador não é responsável por carregar a primeira visualização? Por exemplo, quando carregamos o aplicativo do facebook, o apresentador não é responsável por carregar a página de login?
víbora
2
Um link de Model para View no MVC? Você pode editar sua resposta para explicar como isso o torna um sistema 'dissociado', com esse link. Dica: você pode achar difícil. Além disso, a menos que você ache que o leitor aceitará com satisfação que eles estiveram computando errado a vida toda, você pode querer explicar por que as ações passam pelo Controller primeiro no MVC, apesar de o usuário interagir com os elementos 'visuais' na tela (ou seja, o View), não uma camada abstrata que fica atrás do processamento.
Ash
3
Isso está claramente errado ... no MVC, o modelo nunca fala diretamente com a view e vice-versa. Eles nem sabem que existe outro. O controlador é a cola que os une
MegaManX
1
Eu concordo com Ash e MegaManX. No diagrama MVC, a seta deve ser da Vista apontando para o Modelo (ou ViewModel ou DTO), não do Modelo para a Visualização; porque o Modelo não sabe sobre a Visualização, mas a visualização pode saber sobre o Modelo.
Jboy Flaga
57

Existem muitas respostas para a pergunta, mas senti que é necessário uma resposta realmente simples comparando claramente as duas. Aqui está a discussão que inventei quando um usuário procura um nome de filme em um aplicativo MVP e MVC:

Usuário: Clique em…

Ver : Quem é esse? [ MVP | MVC ]

Usuário: Acabei de clicar no botão de pesquisa…

Ver : Ok, espere um segundo…. [ MVP | MVC ]

( Exibir chamando o Presenter | Controller …) [ MVP | MVC ]

Ver : Hey Apresentador | Controlador , um usuário acabou de clicar no botão de pesquisa, o que devo fazer? [ MVP | MVC ]

Apresentador | Controlador : Hey View , existe algum termo de pesquisa nessa página? [ MVP | MVC ]

Ver : Sim,… aqui está… “piano” [ MVP | MVC ]

Apresentador : Obrigado Ver , ... enquanto isso eu estou procurando-se o termo de pesquisa sobre o modelo , por favor, mostre a ele / ela uma barra de progresso [ MVP | MVC ]

( Apresentador | O controlador está chamando o modelo …) [ MVP | MVC ]

Apresentador | Controlador : Hey Model , você tem alguma correspondência para este termo de pesquisa ?: "piano" [ MVP | MVC ]

Modelo : Hey Presenter | Controlador , deixe-me verificar… [ MVP | MVC ]

(O modelo está fazendo uma consulta ao banco de dados do filme…) [ MVP | MVC ]

( Depois de um tempo ... )

-------------- É aqui que o MVP e o MVC começam a divergir ---------------

Modelo : Encontrei uma lista para você, apresentador , aqui está em JSON “[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993} ] ”[ MVP ]

Modelo : Há algum resultado disponível, Controlador . Eu criei uma variável de campo na minha instância e a preenchi com o resultado. Seu nome é "searchResultsList" [ MVC ]

( Presenter | Controller agradece ao Model e volta à View ) [ MVP | MVC ]

Apresentador : Obrigado pela espera do View , encontrei uma lista de resultados correspondentes e os organizei em um formato apresentável: ["Piano Teacher 2001", "Piano 1993"]. Por favor, mostre-o ao usuário em uma lista vertical. Também oculte a barra de progresso agora [ MVP ]

Controlador : Obrigado por aguardar o View , perguntei ao Model sobre sua consulta de pesquisa. Ele diz que encontrou uma lista de resultados correspondentes e os armazenou em uma variável chamada "searchResultsList" dentro de sua instância. Você pode obtê-lo de lá. Também oculte a barra de progresso agora [ MVC ]

Ver : Muito obrigado Apresentador [ MVP ]

Ver : Obrigado "Controller" [ MVC ] (Agora a View está se questionando: como devo apresentar os resultados que recebo do modelo ao usuário? O ano de produção do filme deve ser o primeiro ou o último ...? estar em uma lista vertical ou horizontal? ...)

Caso você esteja interessado, escrevi uma série de artigos sobre padrões de arquitetura de aplicativos (MVC, MVP, MVVP, arquitetura limpa, ...) acompanhados por um repositório do Github aqui . Mesmo que a amostra seja escrita para o Android, os princípios subjacentes podem ser aplicados a qualquer meio.

Ali Nem
fonte
Basicamente, o que você está tentando dizer é que o controlador gerencia a lógica da visualização? Portanto, torna a visualização mais embaçada, apresentando o que acontece e como está a exibição?
Radu
@Radu, Não, ele não gerencia, é isso que o apresentador faz com que a exibição seja passiva ou muda
237 Ali Ali Nem
4
Em um MVC adequado, a visualização chama a funcionalidade no controlador e ouve as alterações de dados no modelo. A vista não obtém dados do controlador, e o controlador NÃO deve pedir à exibição para exibir, por exemplo, um indicador de carregamento. Um MVC adequado permite substituir a parte da visualização, por uma que seja fundamentalmente diferente. A parte da vista mantém a lógica da vista, que inclui um indicador de carregamento. A visualização chama instruções (no controlador), o controlador modifica os dados no modelo e o modelo notifica seus ouvintes sobre alterações em seus dados; um desses ouvintes é a visualização.
Tommy Andersen
35
  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Ambos os padrões de apresentação. Eles separam as dependências entre um Modelo (pense em objetos de Domínio), sua tela / página da Web (a Visualização) e como sua UI deve se comportar (Apresentador / Controlador)
    2. Eles são bastante similares em conceito; as pessoas inicializam o Apresentador / Controlador de maneira diferente, dependendo do gosto.
    3. Um ótimo artigo sobre as diferenças está aqui . O mais notável é que o padrão MVC tem o Model atualizando a View.
Brett Veenstra
fonte
2
Modelo atualizando o VIew. E esse ainda é um sistema dissociado?
Ash
34

Model-View-Controller

MVC é um padrão para a arquitetura de um aplicativo de software. Ele separa a lógica do aplicativo em três partes separadas, promovendo a modularidade e a facilidade de colaboração e reutilização. Ele também torna os aplicativos mais flexíveis e acolhedores para as iterações. Ele separa um aplicativo nos seguintes componentes:

  • Modelos para manipulação de dados e lógica de negócios
  • Controladores para lidar com a interface do usuário e o aplicativo
  • Visualizações para manipulação de objetos e apresentações da interface gráfica do usuário

Para deixar isso um pouco mais claro, vamos imaginar um aplicativo simples de lista de compras. Tudo o que queremos é uma lista do nome, quantidade e preço de cada item que precisamos comprar esta semana. Abaixo, descreveremos como podemos implementar algumas dessas funcionalidades usando o MVC.

insira a descrição da imagem aqui

Model-View-Presenter

  • O modelo são os dados que serão exibidos na visualização (interface com o usuário).
  • A exibição é uma interface que exibe dados (o modelo) e roteia comandos do usuário (eventos) para o Presenter para atuar com base nesses dados. A visualização geralmente tem uma referência ao seu Apresentador.
  • O apresentador é o "intermediário" (interpretado pelo controlador no MVC) e tem referências a ambos, visualização e modelo. Observe que a palavra "Modelo" é enganosa. Deveria ser a lógica de negócios que recupera ou manipula um modelo . Por exemplo: Se você tiver um usuário armazenando um banco de dados em uma tabela do banco de dados e o seu View desejar exibir uma lista de usuários, o Presenter terá uma referência à lógica comercial do banco de dados (como um DAO) de onde o Presenter consultará uma lista de usuários.

Se você quiser ver uma amostra com implementação simples, verifique este post no GitHub

Um fluxo de trabalho concreto de consulta e exibição de uma lista de usuários de um banco de dados pode funcionar assim: insira a descrição da imagem aqui

Qual é a diferença entre os padrões MVC e MVP ?

Padrão MVC

  • Controladores são baseados em comportamentos e podem ser compartilhados entre visualizações

  • Pode ser responsável por determinar qual visualização exibir (Front Controller Pattern)

Padrão MVP

  • A vista é mais fracamente acoplada ao modelo. O apresentador é responsável por vincular o modelo à visualização.

  • Teste de unidade mais fácil porque a interação com a visualização é feita através de uma interface

  • Geralmente, visualize o mapa do apresentador um a um. Visualizações complexas podem ter vários apresentadores.

Rahul
fonte
2
nah, não há conexão direta entre view e model no mvc. seu diagrama está errado.
Özgür
33

Também vale lembrar que existem diferentes tipos de MVPs. Fowler dividiu o padrão em dois - Controle Passivo de Visão e Supervisão.

Ao usar o Passive View, seu modo de exibição geralmente implementa uma interface refinada com propriedades mapeadas mais ou menos diretamente para o widget subjacente da interface do usuário. Por exemplo, você pode ter um ICustomerView com propriedades como Nome e Endereço.

Sua implementação pode ser algo como isto:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Sua turma do Presenter conversará com o modelo e o "mapeará" para a visualização. Essa abordagem é chamada de "Visão Passiva". O benefício é que a visualização é fácil de testar e é mais fácil alternar entre plataformas de interface do usuário (Web, Windows / XAML, etc.). A desvantagem é que você não pode alavancar coisas como ligação de dados (o que é realmente poderoso em estruturas como WPF e Silverlight ).

O segundo sabor do MVP é o Controlador de Supervisão. Nesse caso, o seu View pode ter uma propriedade chamada Customer, que novamente é vinculada aos widgets da interface do usuário. Você não precisa pensar em sincronizar e gerenciar minuciosamente a exibição, e o Supervising Controller pode intervir e ajudar quando necessário, por exemplo, com lógica de interação completa.

O terceiro "sabor" do MVP (ou alguém poderia chamar isso de padrão separado) é o Modelo de Apresentação (ou algumas vezes chamado de Model-View-ViewModel). Comparado ao MVP, você "mescla" o M e o P em uma classe. Você tem seu objeto de cliente ao qual seus widgets de interface do usuário estão vinculados a dados, mas também possui campos específicos da interface do usuário, como "IsButtonEnabled" ou "IsReadOnly" etc.

Acho que o melhor recurso que encontrei para a arquitetura da interface do usuário é a série de postagens de blog feitas por Jeremy Miller no Índice da série Build Your Own CAB . Ele cobriu todos os tipos de MVP e mostrou o código C # para implementá-los.

Também escrevi no blog sobre o padrão Model-View-ViewModel no contexto do Silverlight no YouCard. Visite novamente: Implementando o padrão ViewModel .

Jonas Follesø
fonte
25

Cada um deles resolve problemas diferentes e pode até ser combinado para ter algo como abaixo

O padrão combinado

Há também uma comparação completa do MVC, MVP e MVVM aqui

Xiaoguo Ge
fonte
1
Em vez de complicar demais as coisas, você poderia ter respondido à pergunta. É por isso que a maioria de nós está aqui. Pesquisei a comparação entre mvp e mvc e fui redirecionado aqui e você está falando sobre a harmonia dessas arquiteturas que não está relacionada ao OP.
Farid
18

Ambas as estruturas visam separar preocupações - por exemplo, interação com uma fonte de dados (modelo), lógica do aplicativo (ou transformar esses dados em informações úteis) (Controller / Presenter) e código de exibição (View). Em alguns casos, o modelo também pode ser usado para transformar uma fonte de dados em uma abstração de nível superior. Um bom exemplo disso é o projeto MVC Storefront .

Há uma discussão aqui sobre as diferenças entre MVC e MVP.

A distinção feita é que em um aplicativo MVC tradicionalmente a visualização e o controlador interagem com o modelo, mas não entre si.

Os designs do MVP permitem que o Presenter acesse o modelo e interaja com a visualização.

Dito isto, o ASP.NET MVC é, por essas definições, uma estrutura MVP, porque o Controller acessa o Model para preencher a View, que não possui lógica (apenas exibe as variáveis ​​fornecidas pelo Controller).

Para talvez ter uma idéia da distinção entre o ASP.NET MVC e o MVP, confira esta apresentação do MIX de Scott Hanselman.

Matt Mitchell
fonte
7
MVC e MVP são padrões, não estruturas. Se você honestamente pensa que esse tópico foi sobre o .NET framework, é como ouvir "a Internet" e pensar que é sobre o IE.
tereško
Tenho certeza de que a pergunta evoluiu significativamente desde a primeira vez que foi feita em 2008. Além disso, olhando para a minha resposta (e isso foi há 4 anos, então eu não tenho muito mais contexto do que você), eu diria que eu geralmente use o .NET MVC como um exemplo concreto.
Matt Mitchell
13

Ambos são padrões que tentam separar a apresentação e a lógica de negócios, dissociando a lógica de negócios dos aspectos da interface do usuário

Arquiteturalmente, o MVP é uma abordagem baseada no Controlador de Página, onde o MVC é uma abordagem baseada no Front Controller. Isso significa que, no MVP, o ciclo de vida da página do formulário da Web é aprimorado apenas extraindo a lógica de negócios do código por trás. Em outras palavras, a página é a única que solicita http. Em outras palavras, o MVP IMHO é um tipo evolutivo de aprimoramento de formulário da web. O MVC, por outro lado, muda completamente o jogo porque a solicitação é interceptada pela classe do controlador antes que a página seja carregada, a lógica de negócios é executada lá e, no resultado final do controlador, processando os dados despejados na página ("visualização"). Nesse sentido, o MVC parece (pelo menos para mim) muito o sabor do MVP do Supervising Controller aprimorado com o mecanismo de roteamento

Ambos permitem TDD e têm desvantagens e desvantagens.

A decisão sobre como escolher um deles IMHO deve basear-se em quanto tempo se investiu no tipo de formulário da Web ASP NET de desenvolvimento da web. Se alguém se considera bom em formulários da web, sugiro MVP. Se alguém não se sentir tão à vontade em coisas como o ciclo de vida da página, etc, o MVC pode ser um caminho a seguir.

Aqui está outro link de postagem no blog, fornecendo um pouco mais de detalhes sobre este tópico

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Nikola Malovic
fonte
9

Eu usei o MVP e o MVC e, embora nós, como desenvolvedores, tendamos a focar nas diferenças técnicas de ambos os padrões, o ponto para o MVP no IMHO está muito mais relacionado à facilidade de adoção do que qualquer outra coisa.

Se estou trabalhando em uma equipe que já possui um bom histórico de estilo de desenvolvimento de formulários da Web, é muito mais fácil introduzir o MVP do que o MVC. Eu diria que o MVP nesse cenário é uma vitória rápida.

Minha experiência me diz que mudar uma equipe de formulários da web para MVP e depois de MVP para MVC é relativamente fácil; mudar de formulários da web para o MVC é mais difícil.

Deixo aqui um link para uma série de artigos que um amigo meu publicou sobre MVP e MVC.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

Pedro Santos
fonte
8

No MVP, a visualização extrai dados do apresentador, que extrai e prepara / normaliza dados do modelo, enquanto no MVC o controlador extrai dados do modelo e do conjunto, pressionando a visualização.

No MVP, você pode ter uma única visualização trabalhando com vários tipos de apresentadores e um único apresentador trabalhando com diferentes visualizações.

O MVP geralmente usa algum tipo de estrutura de ligação, como a estrutura de ligação do Microsoft WPF ou várias estruturas de ligação para HTML5 e Java.

Nessas estruturas, a UI / HTML5 / XAML está ciente de quais propriedades do apresentador cada elemento da interface do usuário exibe; portanto, quando você vincula uma visualização a um apresentador, a visualização procura as propriedades e sabe como extrair dados delas e como para defini-los quando um valor é alterado na interface do usuário pelo usuário.

Portanto, se, por exemplo, o modelo é um carro, o apresentador é uma espécie de apresentador de carro, expõe as propriedades do carro (ano, fabricante, assentos etc.) à exibição. A visualização sabe que o campo de texto chamado 'fabricante de carros' precisa exibir a propriedade Criador do apresentador.

Em seguida, você pode vincular à visualização muitos tipos diferentes de apresentador, todos devem ter a propriedade Maker - ela pode ser de avião, trem ou qualquer outra coisa, a visualização não se importa. A visualização extrai dados do apresentador - não importa qual - desde que implemente uma interface acordada.

Essa estrutura de ligação, se você a reduzir, é na verdade o controlador :-)

E assim, você pode ver no MVP como uma evolução do MVC.

MVC é ótimo, mas o problema é que geralmente o seu controlador por visualização. O Controlador A sabe como definir os campos da Vista A. Se agora, você deseja que a Vista A exiba dados do modelo B, você precisa do Controlador A para conhecer o modelo B ou precisa do Controlador A para receber um objeto com uma interface - como MVP apenas sem as ligações, ou você precisa reescrever o código do conjunto de UI no Controlador B.

Conclusão - O MVP e o MVC são ambos dissociados dos padrões de interface do usuário, mas o MVP geralmente usa uma estrutura de ligações que é o MVC abaixo. O THUS MVP está em um nível arquitetural superior ao MVC e em um padrão de wrapper acima do MVC.

James Roeiter
fonte
6

Minha humilde visão curta: MVP é para grandes escalas e MVC para pequenas escalas. Com o MVC, às vezes sinto que o V e o C podem ser vistos como dois lados de um único componente indivisível, diretamente vinculado a M, e inevitavelmente cai para isso ao descer para escalas mais curtas, como controles de interface do usuário e widgets de base. Nesse nível de granularidade, o MVP faz pouco sentido. Quando alguém, pelo contrário, vai para escalas maiores, a interface adequada se torna mais importante, o mesmo com a atribuição inequívoca de responsabilidades, e aqui vem o MVP.

Por outro lado, essa regra de escala de um polegar pode pesar muito pouco quando as características da plataforma favorecem algum tipo de relação entre os componentes, como com a web, onde parece ser mais fácil implementar o MVC do que o MVP.

Hibou57
fonte
4

Penso que esta imagem de Erwin Vandervalk (e o artigo que o acompanha ) é a melhor explicação do MVC, MVP e MVVM, suas semelhanças e diferenças. O artigo não aparece nos resultados do mecanismo de pesquisa para consultas sobre "MVC, MVP e MVVM" porque o título do artigo não contém as palavras "MVC" e "MVP"; mas é a melhor explicação, eu acho.

imagem explicando MVC, MVP e MVVM - por Erwin Vandervalk

(O artigo também corresponde ao que o tio Bob Martin disse em uma de suas palestras: que o MVC foi originalmente projetado para os pequenos componentes da interface do usuário, não para a arquitetura do sistema)

Jboy Flaga
fonte
3

Existem muitas versões do MVC, esta resposta é sobre o MVC original no Smalltalk. Em resumo, é imagem de mvc vs mvp

This talk droidcon NYC 2017 - Design de aplicativo limpo com componentes de arquitetura esclarece

insira a descrição da imagem aqui insira a descrição da imagem aqui

onmyway133
fonte
6
No MVC o modelo nunca é chamado diretamente a partir da visão
Rodi
5
Esta é uma resposta imprecisa. Não se deixe enganar. como o @rodi escreve, não há interação entre o View e o Model.
precisa
A imagem MVC é imprecisa ou, na melhor das hipóteses, enganosa, por favor, não preste atenção a esta resposta.
Jay
2
@ Jay1b Que MVC você acha que está "correto"? Esta resposta é sobre o MVC original. Há muitos outros MVC (como no iOS) que foi alterado para se adaptar à plataforma, dizer comoUIKit
onmyway133
O que significam as setas?
problemofficer
3

um belo vídeo do tio Bob, onde ele explica brevemente o MVC e o MVP no final.

IMO, MVP é uma versão aprimorada do MVC, onde você basicamente separa a preocupação do que você vai mostrar (os dados) de como você vai mostrar (a exibição). O apresentador inclui um pouco da lógica comercial da sua interface do usuário, impõe implicitamente quais dados devem ser apresentados e fornece uma lista de modelos de exibição idiota. E quando chega a hora de mostrar os dados, você simplesmente conecta sua visualização (provavelmente inclui os mesmos IDs) ao seu adaptador e define os campos de visualização relevantes usando esses modelos de visualização com uma quantidade mínima de código sendo introduzida (apenas usando setters). Seu principal benefício é que você pode testar sua lógica de negócios da interface do usuário em várias / várias visualizações, como mostrar itens em uma lista horizontal ou vertical.

No MVC, falamos através de interfaces (limites) para colar diferentes camadas. Um controlador é um plug-in para nossa arquitetura, mas não tem essa restrição para impor o que mostrar. Nesse sentido, o MVP é uma espécie de MVC com um conceito de visualizações conectável ao controlador através de adaptadores.

Espero que isso ajude melhor.

stdout
fonte
2
Ponto importante do tio Bob: Quando originalmente inventado por Trygve Reenskaug, o MVC foi criado para cada widget, não para todo o formulário.
Basil Bourque
2

Você esqueceu o ADR ( Action-Domain-Responder ).

Conforme explicado em alguns gráficos acima, há uma relação / link direto entre o modelo e a visualização no MVC. Uma ação é executada no Controlador , que executará uma ação no Modelo . Essa ação no modelo , vai desencadear uma reação na exibição . A exibição é sempre atualizada quando o estado do modelo é alterado.

Algumas pessoas continuam esquecendo que o MVC foi criado no final dos anos 70 " e que a Web foi criada apenas no final dos anos 80" / início dos 90 ". O MVC não foi criado originalmente para a Web, mas para aplicativos de área de trabalho, onde o controlador , Model e View coexistiriam juntos.

Como usamos estruturas da Web ( por exemplo: Laravel ) que ainda usam as mesmas convenções de nomenclatura ( model-view-controller ), tendemos a pensar que deve ser o MVC, mas na verdade é outra coisa.

Em vez disso, dê uma olhada no Action-Domain-Responder . No ADR, o Controlador obtém uma Ação , que executará uma operação no Modelo / Domínio . Até agora, o mesmo. A diferença é que, em seguida, ele coleta a resposta / dados dessa operação e os passa para um Respondente ( por exemplo :.view() ) para renderização. Quando uma nova ação é solicitada no mesmo componente, o Controlador é chamado novamente e o ciclo se repete. No ADR, não há conexão entre o Modelo / Domínio e a Visualização ( resposta do Reponser ).

Nota: A Wikipedia afirma que " cada ação de ADR, no entanto, é representada por classes ou fechamentos separados ". Isto não é necessariamente verdade. Várias ações podem estar no mesmo controlador e o padrão ainda é o mesmo.

Hugo Rafael Azevedo
fonte
2

A resposta mais simples é como a visualização interage com o modelo. No MVP, a visualização é atualizada pelo apresentador, que atua como intermediário entre a visualização e o modelo. O apresentador pega a entrada da visualização, que recupera os dados do modelo e, em seguida, executa qualquer lógica de negócios necessária e, em seguida, atualiza a visualização. No MVC, o modelo atualiza a visualização diretamente, em vez de voltar pelo controlador.

Clive Jefferies
fonte
Eu diminuí a votação, porque o modelo não sabe nada sobre a exibição no MVC e não é possível atualizá-lo diretamente enquanto você escreve.
Problema #
1
Veja o MVC na Wikipedia, é exatamente assim que funciona.
Clive Jefferies
1
Quer os leitores gostem ou não, muitas fontes que podem ser encontradas pesquisando afirmam que no MVC a visualização assina atualizações no modelo. e, em alguns casos, pode até ser o controlador e, portanto, chamar essas atualizações. Se você não gosta disso, vá reclamar sobre esses artigos ou cite qual 'bíblia' você acha que é a única fonte legítima, em vez de votar abaixo das respostas que apenas transmitem as outras informações disponíveis no mercado!
Sublinhado #
1
Definitivamente, a redação poderia ser melhorada, mas é verdade que a visualização assina alterações no modelo no MVC. O modelo não precisa conhecer a Visualização no MVC.
devorou ​​elysium
obrigado .. me ajudou muito
Dvyn Resh
1
  • No MVC, o View possui a parte da interface do usuário, o controller é o mediador entre o view e o model e o model contém a lógica de negócios.
  • No MVP, o View contém a interface do usuário e a implementação do apresentador, pois aqui o apresentador é apenas uma interface e o modelo é o mesmo, ou seja, contém lógica de negócios.
Chinmai Kulkarni
fonte
-1

MVP

MVP significa Model - View- Presenter. Isso chegou a um ponto no início de 2007, em que a Microsoft introduziu aplicativos para janelas do Smart Client.

Um apresentador está atuando como uma função de supervisão no MVP que vincula os eventos do View e a lógica de negócios dos modelos.

A associação de eventos de exibição será implementada no Presenter a partir de uma interface de exibição.

A visualização é o iniciador das entradas do usuário e, em seguida, delega os eventos para o Presenter e o apresentador lida com ligações de eventos e obtém dados dos modelos.

Prós: a visualização possui apenas interface do usuário e nenhuma lógica Alto nível de testabilidade

Contras: Pouco complexo e mais trabalhos ao implementar ligações de eventos

MVC

MVC significa Model-View-Controller. O Controller é responsável por criar modelos e renderizar visualizações com modelos de ligação.

Controller é o iniciador e decide qual visualização renderizar.

Prós: Ênfase no princípio da responsabilidade única Alto nível de testabilidade

Contras: Às vezes, muita carga de trabalho para os controladores, se tentar renderizar várias visualizações no mesmo controlador.

marvelTracker
fonte