O que são MVP e MVC e qual a diferença?
https://stackoverflow.com/questions/2056
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Ao olhar além do RAD (arrastar, soltar e configurar) maneira de construir interfaces de usuário que muitas ferramentas incentivam, você provavelmente encontrará três padrões de design chamados Controlador de visualização de modelo, Apresentador de visualização de modelo e Modelo-Visualização-ViewModel.Minha pergunta tem três partes:
- Que questões esses padrões abordam?
- Como eles são semelhantes?
- Como eles são diferentes?
Solução
Apresentador de visualização de modelo
Em MVP, o Presenter contém a lógica de negócios da UI para a Visualização.Todas as invocações do View são delegadas diretamente ao Presenter.O Presenter também é desacoplado diretamente da Visualização e se comunica com ela por meio de uma interface.Isso permite a simulação do View 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.Assim que o salvamento for concluído, o Presenter chamará de volta a Visualização por meio de sua interface para que a Visualização possa exibir que o salvamento foi concluído.
MVP tende a ser um padrão muito natural para obter apresentações separadas em Web Forms.A razão é que a Visualização é sempre criada primeiro pelo tempo de execução do ASP.NET.Você pode saiba mais sobre ambas as variantes.
Duas variações principais
Visão Passiva: O View é o mais burro possível e contém quase zero lógica.O Apresentador é um intermediário que conversa com a Visualização e o Modelo.A Visualização e o Modelo são completamente protegidos um do outro.O Modelo pode gerar eventos, mas o Presenter os inscreve para atualizar a Visualização.Na Visualização Passiva não há ligação direta de dados; em vez disso, a Visualização expõe propriedades do setter que o Presenter usa para definir os dados.Todo o estado é gerenciado no Presenter e não no View.
- Pró:superfície máxima de testabilidade;separação limpa da vista e do modelo
- Vigarista:mais trabalho (por exemplo, todas as propriedades do setter), pois você mesmo faz toda a ligação de dados.
Controlador Supervisor: O Presenter lida com os gestos do usuário.A Visualização se liga ao Modelo diretamente por meio da vinculação de dados.Nesse caso, é função do Presenter passar o Modelo para a Visualização para que ele possa se vincular a ele.O Presenter também conterá lógica para gestos como pressionar um botão, navegação, etc.
- Pró:aproveitando a ligação de dados, a quantidade de código é reduzida.
- Vigarista:há menos superfície testável (por causa da ligação de dados) e há menos encapsulamento na Visualização, pois ela se comunica diretamente com o Modelo.
Controlador de visualização de modelo
No MVC, o Controlador é responsável por determinar qual Visualização será exibida em resposta a qualquer ação, inclusive quando o aplicativo for carregado.Isso difere do MVP, onde as ações passam pela Visualização até o Presenter.No MVC, cada ação na Visualização se correlaciona com uma chamada para um Controlador junto com uma ação.Na web cada ação envolve uma chamada para uma URL do outro lado da qual existe um Controlador que responde.Assim que esse Controlador concluir seu processamento, ele retornará a Visualização correta.A sequência continua dessa maneira durante toda a vida do aplicativo:
Action in the View
-> Call to Controller
-> Controller Logic
-> Controller returns the View.
Uma outra grande diferença sobre o MVC é que a Visualização não se liga diretamente ao Modelo.A visualização simplesmente é renderizada e é completamente sem estado.Em implementações de MVC a View normalmente não terá nenhuma 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
Um outro padrão a ser observado é o Modelo de apresentação padrão.Neste padrão não há apresentador.Em vez disso, a Visualização se liga 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 seriam colocadas em um modelo de domínio, pois seria uma violação da separação de preocupações.Neste caso, o Modelo de Apresentação liga-se ao modelo de domínio e pode subscrever eventos provenientes desse Modelo.A Visualização então assina eventos provenientes do Modelo de Apresentação e se atualiza de acordo.O modelo de apresentação pode expor comandos que a visualização usa para invocar ações.A vantagem dessa abordagem é que você pode essencialmente remover completamente o code-behind, já que o PM encapsula completamente todo o comportamento da visualização.Esse padrão é um forte candidato para uso em aplicativos WPF e também é chamado Modelo-Visualização-ViewModel.
Existe um Artigo do MSDN sobre o modelo de apresentação e uma seção no Orientação de aplicação composta para WPF (antigo Prisma) sobre Padrões de apresentação separados
Outras dicas
Esta é uma simplificação exagerada das muitas variantes desses padrões de design, mas é assim que gosto de pensar sobre as diferenças entre os dois.
MVC
MVP
Eu escrevi sobre isso há algum tempo, citando em Excelente postagem 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 visão está mais fracamente acoplada ao modelo.O apresentador é responsável por vincular o modelo à visualização.
- Mais fácil de fazer o teste de unidade porque a interação com a visualização é através de uma interface
- Geralmente visualiza o mapa do apresentador um para um.Visões complexas podem ter vários apresentadores.
Padrão MVC
- O controlador é baseado em comportamentos e pode ser compartilhado entre visualizações
- Pode ser responsável por determinar qual visualização exibir
É a melhor explicação na web que pude encontrar.
Aqui estão ilustrações que representam o fluxo de comunicação
MVP é não necessariamente um cenário onde o View está no comando (veja o MVP do Taligent, por exemplo).
Acho lamentável que as pessoas ainda estejam pregando isso como um padrão (Visão responsável) em oposição a um antipadrão, pois contradiz "É apenas uma visão" (Programador Pragmático).“É apenas uma visualização” afirma que a visualização final mostrada ao usuário é uma preocupação secundária do aplicativo.O padrão MVP da Microsoft torna a reutilização de Views muito mais difícil e convenientemente desculpa o designer da Microsoft de encorajar más práticas.
Para ser franco, acho que as preocupações subjacentes do MVC são verdadeiras para qualquer implementação de MVP e as diferenças são quase inteiramente semânticas.Contanto que você siga 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)), você estará obtendo os benefícios do MVC .Se você está obtendo os benefícios, quem realmente se importa se seu padrão é MVC, MVP ou Controlador de Supervisão?A única real padrão permanece como MVC, o resto são apenas sabores diferentes dele.
Considerar esse artigo altamente interessante que lista de forma abrangente várias dessas diferentes implementações.Você pode notar que todos eles estão basicamente fazendo a mesma coisa, mas de maneira um pouco diferente.
Pessoalmente, acho que MVP só foi recentemente reintroduzido como um termo cativante para reduzir discussões entre fanáticos semânticos que discutem se algo é realmente MVC ou não, ou para justificar as ferramentas de desenvolvimento rápido de aplicativos da Microsoft.Nenhuma dessas razões em meus livros justifica sua existência como um padrão de design separado.
MVP:a visã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 através de uma interface.A visualização às vezes interagirá com o apresentador, geralmente por meio de alguma interface.Isto se resume à implementação;você deseja que a visualização chame métodos no apresentador ou deseja que a visualização tenha eventos que o apresentador escuta?Tudo se resume a isso:A visualização conhece o apresentador.A visualização delega ao apresentador.
MVC:o controlador está no comando.
O controlador é criado ou acessado com base em algum evento/solicitação.O controlador então 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 visualização;a visualização é escrava do controlador.A visualização não conhece o controlador.
MVC (controlador de visualização de modelo)
A entrada é direcionada primeiro ao Controlador, não à visualização.Essa entrada pode vir de um usuário interagindo com uma página, mas também pode ser simplesmente inserindo um URL específico em um navegador.Em ambos os casos, é um controlador com interface para iniciar algumas funcionalidades.Existe um relacionamento muitos-para-um entre o Controlador e a Visualização.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 unidirecional do Controlador para a Visualização.Isso ocorre porque a View não tem nenhum conhecimento ou referência ao controlador.O Controlador devolve o Modelo, portanto, há conhecimento entre a Visualização e o Modelo esperado sendo passado para ele, mas não o Controlador que o atende.
MVP (apresentador de visualização de modelo)
A entrada começa com o View, não com o Presenter.Há um mapeamento um-para-um entre a Visualização e o Presenter associado.A View contém uma referência ao Presenter.O Presenter também está reagindo a eventos acionados a partir da Visualização, portanto, está ciente da Visualização à qual está associado.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
Há muitas respostas para a pergunta, mas senti que há necessidade de uma resposta realmente simples, comparando claramente as duas.Aqui está a discussão que criei quando um usuário pesquisa o nome de um filme em um aplicativo MVP e MVC:
Do utilizador:Clique, clique…
Visualizar:Quem é aquele?[MVP|MVC]
Do utilizador:Acabei de clicar no botão de pesquisa…
Visualizar:Ok, espere um segundo….[MVP|MVC]
( Visualizar ligando para o Apresentador|Controlador … ) [MVP|MVC]
Visualizar:Ei Apresentador|Controlador, um usuário acabou de clicar no botão de pesquisa, o que devo fazer?[MVP|MVC]
Apresentador|Controlador:Ei Visualizar, existe algum termo de pesquisa nessa página?[MVP|MVC]
Visualizar:Sim,… aqui está… “piano” [MVP|MVC]
Apresentador:Obrigado Visualizar,… enquanto isso estou procurando o termo de pesquisa no Modelo, mostre a ele uma barra de progresso [MVP|MVC]
( Apresentador|Controlador está ligando para o Modelo … ) [MVP|MVC]
Apresentador|Controlador:Ei Modelo, Você tem alguma correspondência para este termo de pesquisa?:“piano” [MVP|MVC]
Modelo:Ei Apresentador|Controlador, deixe-me ver … [MVP|MVC]
( Modelo está fazendo uma consulta ao banco de dados de filmes…) [MVP|MVC]
( Depois de um tempo ...)
----------------- É aqui que MVP e 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.Criei uma variável de campo na minha instância e preenchi-a com o resultado.Seu nome é "searchResultsList" [MVC]
(Apresentador|Controlador obrigado Modelo e volta para o Visualizar) [MVP|MVC]
Apresentador:Obrigado por esperar Visualizar, encontrei uma lista de resultados correspondentes para você e os organizei em um formato apresentável:["Professor de Piano 2001","Piano 1993"].Mostre-o ao usuário em uma lista vertical.Além disso, oculte a barra de progresso agora [MVP]
Controlador:Obrigado por esperar Visualizar, Eu perguntei Modelo 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 a partir daí.Além disso, oculte a barra de progresso agora [MVC]
Visualizar:Muito obrigado Apresentador [MVP]
Visualizar:Obrigado "Controlador" [MVC] (Agora o Visualizar está se questionando:Como devo apresentar os resultados que obtenho do Modelo para o usuário?O ano de produção do filme deve vir primeiro ou último...?Deveria estar em uma lista vertical ou horizontal?...)
Caso você esteja interessado, estou escrevendo uma série de artigos tratando de padrões de arquitetura de aplicativos (MVC, MVP, MVVP, arquitetura limpa, ...) acompanhados de um repositório Github aqui.Embora o exemplo tenha sido escrito para Android, os princípios subjacentes podem ser aplicados a qualquer meio.
- MVP = Apresentador de visualização de modelo
MVC = Controlador de Visualização de Modelo
- 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)
- Eles são bastante semelhantes em conceito, as pessoas inicializam o Presenter/Controller de maneira diferente, dependendo do gosto.
- Um ótimo artigo sobre as diferenças é aqui.O mais notável é que o padrão MVC faz com que o modelo atualize a visualização.
Também vale lembrar que existem diferentes tipos de MVPs.Fowler dividiu o padrão em dois - Visão Passiva e Controlador de Supervisão.
Ao usar o Passive View, seu View normalmente implementa uma interface refinada com propriedades mapeadas mais ou menos diretamente para o widget de UI subjacente.Por exemplo, você pode ter um ICustomerView com propriedades como Nome e Endereço.
Sua implementação pode ser parecida com isto:
public class CustomerView : ICustomerView
{
public string Name
{
get { return txtName.Text; }
set { txtName.Text = value; }
}
}
Sua classe Presenter conversará com o modelo e o “mapeará” para a visualização.Essa abordagem é chamada de “Visão Passiva”.A vantagem é que a visualização é fácil de testar e é mais fácil mover-se entre plataformas de UI (Web, Windows/XAML, etc.).A desvantagem é que você não pode aproveitar coisas como ligação de dados (que é realmente poderoso em estruturas como WPF e luz cinza).
O segundo tipo de MVP é o Controlador de Supervisão.Nesse caso, sua Visualização pode ter uma propriedade chamada Cliente, que novamente está vinculada aos widgets da UI.Você não precisa pensar em sincronizar e microgerenciar a visualização, e o Controlador Supervisor pode intervir e ajudar quando necessário, por exemplo, com lógica de interação completa.
O terceiro "sabor" do MVP (ou alguém talvez o chamaria de padrão separado) é o Modelo de Apresentação (ou às vezes referido como 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 UI estão vinculados aos dados, mas também tem campos adicionais específicos da UI, como "IsButtonEnabled" ou "IsReadOnly", etc.
Acho que o melhor recurso que encontrei para arquitetura de UI é a série de postagens feitas por Jeremy Miller em O índice Crie sua própria série CAB.Ele abordou todos os tipos de MVP e mostrou o código C# para implementá-los.
Também escrevi em um blog sobre o padrão Model-View-ViewModel no contexto do Silverlight em YouCard revisitado:Implementando o padrão ViewModel.
Controlador de visualização de modelo
MVC é um padrão para a arquitetura de um aplicativo de software.Ele separa a lógica do aplicativo em três partes distintas, promovendo modularidade e facilidade de colaboração e reutilização.Também torna os aplicativos mais flexíveis e receptivos às iterações. Ele separa um aplicativo nos seguintes componentes:
- Modelos para lidar com dados e lógica de negócios
- Controladores para lidar com a interface do usuário e o aplicativo
- Visualizações para lidar com 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 com o nome, quantidade e preço de cada item que precisamos comprar esta semana.Abaixo descreveremos como poderíamos implementar algumas dessas funcionalidades usando MVC.
Apresentador de visualização de modelo
- O modelo são os dados que serão exibidos na visualização (interface do usuário).
- O visualizar é uma interface que exibe dados (o modelo) e roteia comandos do usuário (eventos) para o Presenter agir de acordo com esses 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 para visualização e modelo. Observe que a palavra “Modelo” é enganoso.Deveria antes ser lógica de negócios que recupera ou manipula um modelo.Por exemplo:Se você tiver um banco de dados armazenando User em uma tabela de banco de dados e sua View quiser exibir uma lista de usuários, então o Presenter terá uma referência à lógica de negócios do seu banco de dados (como um DAO) de onde o Presenter consultará uma lista de usuários.
Se você quiser ver um exemplo com implementação simples, verifique esse postagem no github
Um fluxo de trabalho concreto de consulta e exibição de uma lista de usuários de um banco de dados poderia funcionar assim:
O que é diferença entre MVC e MVP padrões?
Padrão MVC
O controlador é baseado em comportamentos e pode ser compartilhado entre visualizações
Pode ser responsável por determinar qual visualização exibir (padrão do controlador frontal)
Padrão MVP
A visão está mais fracamente acoplada ao modelo.O apresentador é responsável por vincular o modelo à visualização.
Mais fácil de testar a unidade porque a interação com a visualização é feita por meio de uma interface
Geralmente visualiza o mapa do apresentador um para um.Visualizações complexas podem ter vários apresentadores.
Cada um deles aborda problemas diferentes e podem até ser combinados para obter algo como abaixo
Ambas as estruturas visam separar preocupações - por exemplo, interação com uma fonte de dados (modelo), lógica de aplicação (ou transformar esses dados em informações úteis) (Controlador/Apresentador) e código de exibição (Visualização).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 em relação às diferenças entre MVC vs MVP.
A distinção feita é que em uma aplicação MVC tradicionalmente a visualização e o controlador interagem com o modelo, mas não entre si.
Os designs MVP fazem com 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 Controlador acessa o Modelo para preencher a Visualização que não deve ter lógica (apenas exibe as variáveis fornecidas pelo Controlador).
Para talvez ter uma ideia da distinção entre ASP.NET MVC e MVP, confira esta apresentação MIX por Scott Hanselman.
Ambos são padrões que tentam separar a lógica de apresentação e de negócios, dissociando a lógica de negócios dos aspectos da UI
Arquitetonicamente, MVP é uma abordagem baseada em Page Controller, enquanto MVC é uma abordagem baseada em Front Controller.Isso significa que no MVP o ciclo de vida da página do formulário da web padrão é aprimorado apenas pela extração da lógica de negócios do código por trás.Em outras palavras, a página é aquela que atende à solicitação http.Em outras palavras, MVP IMHO é um tipo de aprimoramento evolutivo de formulário da web.O MVC, por outro lado, muda completamente o jogo porque a solicitação é interceptada pela classe do controlador antes da carga da página ser carregada, a lógica de negócios é executada lá e, no final, resultado do processamento do controlador que os dados acabaram de despejar na página ("View") nisso Sentido, o MVC parece (pelo menos para mim) muito para supervisionar o sabor do controlador de MVP aprimorado com o motor de roteamento
Ambos habilitam o TDD e têm desvantagens e vantagens.
A decisão sobre como escolher um deles IMHO deve ser baseada em quanto tempo foi investido no tipo de desenvolvimento web ASP NET.Se alguém se considera bom em formulários web, eu sugeriria MVP.Se alguém não se sentir tão confortável com coisas como ciclo de vida da página, etc., o MVC pode ser uma opção aqui.
Aqui está mais um link de postagem no blog com um pouco mais de detalhes sobre este tópico
Eu usei MVP e MVC e embora nós, como desenvolvedores, tendamos a nos concentrar nas diferenças técnicas de ambos os padrões, o ponto do MVP no IMHO está muito mais relacionado à facilidade de adoção do que qualquer outra coisa.
Se estou trabalhando em uma equipe que já tem uma boa experiência no estilo de desenvolvimento de formulários web, é muito mais fácil introduzir o MVP do que o MVC.Eu diria que o MVP neste cenário é uma vitória rápida.
Minha experiência me diz que mover uma equipe de formulários web para MVP e depois de MVP para MVC é relativamente fácil;mudar de formulários da web para 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
No MVP a visualização extrai dados do apresentador que desenha e prepara/normaliza os dados do modelo, enquanto no MVC o controlador extrai dados do modelo e define, por push na 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 múltiplas.
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 qual propriedade do apresentador cada elemento da UI 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 IU pelo usuário.
Então, se, por exemplo, o modelo é um carro, então o apresentador é uma espécie de apresentador de carro, expõe as propriedades do carro (ano, fabricante, assentos, etc.) à visualização.A visualização sabe que o campo de texto chamado 'fabricante de automóveis' precisa exibir a propriedade Maker do apresentador.
Você pode então vincular à visualização muitos tipos diferentes de apresentador, todos devem ter a propriedade Maker - pode ser de um avião, trem ou o que quer que seja, a visualização não 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ê desmontá-la, é na verdade o controlador :-)
E assim, você pode ver o MVP como uma evolução do MVC.
MVC é ótimo, mas o problema é que geralmente é controlador por visualização.O Controlador A sabe como definir campos da Visualização A.Se agora você deseja que a Visualização 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 - que é como o MVP apenas sem as ligações, ou você precisa reescrever o código do conjunto de UI no Controlador B.
Conclusão - MVP e MVC são ambos dissociados de padrões de UI, mas o MVP geralmente usa uma estrutura de ligações que é MVC por baixo.ASSIM, o MVP está em um nível de arquitetura mais alto que o MVC e um padrão de wrapper acima do MVC.
Minha humilde visão resumida: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 ligado ao M, e inevitavelmente caimos nisso quando descemos para escalas mais curtas, como controles de UI e widgets básicos.Nesse nível de granularidade, o MVP faz pouco sentido.Quando, pelo contrário, vamos para escalas maiores, a interface adequada torna-se mais importante, o mesmo com a atribuição inequívoca de responsabilidades, e aí vem o MVP.
Por outro lado, esta regra de escala pode pesar muito pouco quando as características da plataforma favorecem algum tipo de relação entre os componentes, como acontece com a web, onde parece ser mais fácil implementar MVC, mais do que MVP.
Há esse belo vídeo do tio Bob, onde ele explica brevemente MVC e MVP no final.
IMO, MVP é uma versão melhorada do MVC onde você basicamente separa a preocupação do que vai mostrar (os dados) de como vai mostrar (a visualização).O Presenter inclui a lógica de negócios da sua UI, impõe implicitamente quais dados devem ser apresentados e fornece uma lista de modelos de visualização idiotas.E quando chegar a hora de mostrar os dados, basta conectar sua visualização (provavelmente inclui os mesmos IDs) em seu adaptador e definir 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 a lógica de negócios da interface do usuário em muitas/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.Controller é um plug-in para nossa arquitetura, mas não possui tal restrição para impor o que mostrar.Nesse sentido, o MVP é uma espécie de MVC com o conceito de visualizações conectáveis ao controlador por meio de adaptadores.
Espero que isso ajude melhor.
Existem muitas versões do MVC, esta resposta é sobre o MVC original em Smalltalk.Em resumo, é
Esta conversa droidcon NYC 2017 - Design de aplicativo limpo com componentes de arquitetura esclarece isso
A resposta mais simples é como a visualização interage com o modelo.No MVP a visão está vinculada ao apresentador, que atua como intermediário entre a visão e o modelo, obtendo informações da visão, obtendo dados do modelo, depois executando uma lógica de negócio e finalmente atualizando a visão.No MVC, o modelo atualiza a visualização diretamente, em vez de voltar pelo controlador.
Acho que esta imagem de Erwin Vandervalk (e a que a acompanha artigo) é a melhor explicação de 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.
(O artigo também corresponde ao que o tio Bob Martin disse em uma de suas palestras:que o MVC foi originalmente projetado para pequenos componentes de UI, não para a arquitetura do sistema)
MVP
MVP significa Modelo - Visualização - Apresentador.Isso veio à tona no início de 2007, quando a Microsoft lançou aplicativos Smart Client para Windows.
O apresentador atua como uma função de supervisão no MVP que vincula a visualização de eventos e lógicas de negócios dos modelos.
A vinculação de eventos de visualização será implementada no Presenter a partir de uma interface de visualização.
View é o iniciador das entradas do usuário e, em seguida, delega os eventos ao Presenter e o apresentador manipula as ligações de eventos e obtém dados dos modelos.
Prós:A visualização está tendo apenas uma interface do usuário não lógica de alto nível de testabilidade
Contras:Um pouco complexo e mais trabalhoso ao implementar vinculações de eventos
MVC
MVC significa Model-View-Controller.O controlador é responsável por criar modelos e renderizar visualizações com modelos vinculativos.
O controlador é o iniciador e decide qual visualização renderizar.
Prós:Ênfase no princípio de responsabilidade única Alto nível de testabilidade
Contras:Às vezes, há muita carga de trabalho para os controladores, se tentar renderizar várias visualizações no mesmo controlador.
