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

votos
1k

Ao olhar para além da RAD maneira de construir interfaces de usuário que muitas ferramentas incentivar que são susceptíveis de se deparar com três padrões de projeto chamado (arrastar-soltar e configurar) Model-View-Controller , Model-View-Presenter e Model-View-ViewModel . A minha pergunta tem três partes:

  1. Quais as questões que esses padrões de endereço?
  2. Como são semelhantes?
  3. Como eles são diferentes?
Publicado 05/08/2008 em 11:06
fonte usuário
Em outras línguas...                            


27 respostas

votos
1k

Model-View-Presenter

No MVP , o Presenter contém a lógica de negócios UI para a vista. Todas as invocações do ponto de vista delegado diretamente ao apresentador. O apresentador também é desacoplada directamente a partir da vista e fala a ele através de uma interface. Isto é para permitir zombeteiro da View em um teste de unidade. Um atributo comum de MVP é que tem de haver uma grande quantidade de mão dupla expedição. Por exemplo, quando alguém clica no botão "Save", os representantes de manipulador de evento ao método "OnSave" do apresentador. Uma vez que o salvamento for concluído, o apresentador, então, chamar de volta o Vista através de sua interface para que a exibição pode mostrar que o salvamento foi concluída.

MVP tende a ser um padrão muito natural para alcançar a apresentação separada na Web Forms. A razão é que a vista é sempre criada pela primeira vez pelo tempo de execução ASP.NET. Você pode saber mais sobre ambas as variantes .

Duas variações primárias

Ver passiva: The View é tão idiota quanto possível e contém quase zero lógica. O Presenter é um homem de meia que fala com a vista eo modelo. The View e Modelo são completamente blindado um do outro. O modelo pode gerar eventos, mas o Presenter subscreve a eles para atualizar o View. Em Passive View existe ligação há dados diretos, em vez da exibição expõe propriedades setter que o apresentador usa para definir os dados. Todos Estado é gerida no Presenter e não a vista.

  • Pro: superfície máxima capacidade de teste; separação limpa da Visão e Modelo
  • Con: mais trabalho (por exemplo, todas as propriedades setter) como você está fazendo todos os dados se obrigatório.

Supervisão Controlador: O Presenter lida com gestos do usuário. The View liga-se ao Modelo directamente através de ligação de dados. Neste caso, é o trabalho do Presenter para passar fora do modelo para a vista de modo que possa se ligar a ele. O Presenter também conterá a lógica para gestos como apertar um botão, navegação, etc.

  • Pro: potenciando ligação de dados a quantidade de código é reduzida.
  • Con: há menos superfície testável (por causa da ligação de dados), e há menos de encapsulamento na Vista uma vez que fala diretamente ao modelo.

MVC

No MVC , o controlador é responsável por determinar quais View para exibir em resposta a qualquer acção, incluindo quando o aplicativo é carregado. Isso difere do MVP onde as ações rota através do Vista para o Presenter. No MVC, cada ação na Vista correlaciona-se com uma chamada para um controlador juntamente com uma ação. Na web cada ação envolve uma chamada para um URL no outro lado da qual há um controlador que responde. Uma vez que controlador concluiu seu processamento, ele irá retornar a visão correta. A sequência continua, em que a forma em toda a vida do pedido:

    Ação na Vista
        -> Chamada ao Controlador
        -> Logic Controller
        -> Controlador retorna a View.

Uma outra grande diferença sobre MVC é que a vista não se liga diretamente ao modelo. O ponto de vista simplesmente torna, e é completamente sem estado. Em implementações de MVC View costuma não ter qualquer lógica no código por trás. Isto é contrário ao MVP onde é absolutamente necessário, porque, se a exibição não delega para o apresentador, ele nunca vai obter chamado.

apresentação Modelo

Um outro padrão é olhar para o modelo de apresentaçãopadronizar. Nesse padrão não há Presenter. Em vez da exibição se liga diretamente a um modelo de apresentação. A apresentação modelo é um modelo trabalhada especificamente para a View. Isto significa que este modelo pode expor propriedades que nunca iria colocar 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 se inscrever em eventos provenientes desse modelo. The View, em seguida, subscreve a eventos provenientes do modelo de apresentação e se atualiza em conformidade. O modelo de apresentação pode expor os comandos que a visão usa para invocar ações. A vantagem dessa abordagem é que você pode essencialmente remover o código-behind completamente como o PM encapsula completamente todo o comportamento para a vista.Model-View-ViewModel .

Há um artigo MSDN sobre o modelo de apresentação e uma seção no Composite Application Guidance for WPF (ex Prism) sobre Padrões de apresentação Separados

Respondeu 19/09/2008 em 13:46
fonte usuário

votos
381

Eu escrevi sobre isso um tempo atrás, citando em 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

  • Ver é mais fracamente acoplada ao modelo. O apresentador é responsável pela ligação do modelo à vista.
  • Mais fácil de teste de unidade porque a interacção com a visualização é por meio de uma interface
  • Normalmente visualizar a mapa apresentador 1-1. visualizações complexas podem ter múltiplos apresentadores.

Pattern MVC

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

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

Respondeu 05/08/2008 em 11:21
fonte usuário

votos
358

Esta é uma simplificação das muitas variantes destes padrões de projeto, mas é assim que eu gosto de pensar sobre as diferenças entre os dois.

MVC

MVC

MVP

digite descrição da imagem aqui

Respondeu 06/07/2013 em 23:18
fonte usuário

votos
202

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

digite descrição da imagem aqui

digite descrição da imagem aqui

Respondeu 12/09/2014 em 21:47
fonte usuário

votos
147

MVP é não necessariamente um cenário onde a vista é responsável (ver MVP do Taligent por exemplo).
Acho que é lamentável que as pessoas ainda estão pregando isso como um padrão (Ver no comando) em oposição a um anti-padrão, uma vez que contradiz "É apenas uma visão" (Pragmatic Programmer). "É apenas uma opinião", afirma que a visão final mostrado para o usuário é uma preocupação secundária do aplicativo. Padrão MVP da Microsoft torna reutilização de Visualizações muito mais difícil e convenientemente desculpas de designer da Microsoft de incentivar a prática ruim.

Para ser franco, acho que as preocupações subjacentes da MVC são verdadeiras para qualquer implementação MVP e as diferenças são quase inteiramente semântica. Enquanto você está seguindo separação de interesses entre a visão (que exibe os dados), o controlador (que inicializa e controla a interacção do utilizador) eo modelo (os subjacentes de dados e / ou serviços)), então você está acheiving os benefícios do MVC . Se você está acheiving os benefícios, em seguida, que realmente se importa se o seu padrão é MVC, MVP ou Supervising Controller? O único verdadeiro padrão permanece como MVC, o resto são apenas diferentes sabores do mesmo.

Considere este artigo altamente emocionante que exaustivamente enumera uma série de essas implementações diferentes. Você pode notar que eles estão todos fazendo basicamente a mesma coisa, mas de forma ligeiramente diferente.

Eu pessoalmente acho que MVP só recentemente foi re-introduzido como um termo catchy que quer reduzir argumentos entre fanáticos semânticas que argumentam se algo é verdadeiramente MVC ou não, ou para justificar Ferramentas de Desenvolvimento Microsofts aplicação rápida. Nenhuma dessas razões em meus livros justificar a sua existência como um padrão de projeto separado.

Respondeu 25/08/2008 em 22:22
fonte usuário

votos
85

MVP: o ponto de vista está no comando.

A vista, na maioria dos casos, cria seu apresentador. O apresentador vai interagir com o modelo e manipular a vista através de uma interface. A visão, por vezes, interagir com o apresentador, normalmente através de alguma interface. Isso se resume a implementação; você quer a fim de chamar métodos em que o apresentador ou você quer a fim de ter eventos o apresentador escutam? Tudo se resume a isto: A exibição sabe sobre o apresentador. Os vista delegados para o apresentador.

MVC: o controlador está no comando.

O controlador é criado ou acessado base em algum evento / pedido. O controlador, então, cria a visualização adequada e interage com o modelo para configurar ainda mais a vista. Tudo se resume a: o controlador cria e gerencia o ponto de vista; a vista é escravo para o controlador. A visão não sabe sobre o controlador.

Respondeu 06/08/2008 em 23:51
fonte usuário

votos
58

digite descrição da imagem aqui

MVC (Model View Controller)

A entrada é dirigido para o controlador primeiro, não a vista. Essa entrada pode estar vindo de um usuário interagindo com uma página, mas também pode ser de simplesmente digitando uma URL específica em um navegador. Em qualquer caso, é um controlador que está conectado com a lançar algumas funcionalidades. Há um relacionamento muitos-para-um entre o controlador eo modo de exibição. Isso porque um único controlador pode selecionar diferentes pontos de vista a serem prestados com base na operação que está sendo executada. Note-se a uma forma de seta do Controlador para ver. Isso ocorre porque a vista não tem qualquer conhecimento ou referência para o controlador. O controlador faz passar de volta o modelo, para que haja conhecimento entre a vista eo Modelo esperada sendo passados ​​para ele, mas não o controlador servindo-lo.

MVP (Model View Presenter)

A entrada começa com a exibição, não o apresentador. Há um mapeamento um-para-um entre a vista eo Apresentador associado. The View contém uma referência para o apresentador. O Presenter também está reagindo a eventos que estão sendo desencadeado a partir da Visão, pelo que a sua consciência do Ver seu associado. O Presenter atualiza a exibição com base nas ações solicitadas que executa no modelo, mas a vista não é o modelo consciente.

Para mais Referência

Respondeu 20/12/2015 em 02:10
fonte usuário

votos
31

Também vale a pena lembrar é que existem diferentes tipos de MVPs também. Fowler tem quebrado o padrão em dois - Ver passiva e controlador de Supervisão.

Ao usar Passive View, a sua exibição tipicamente implementar uma interface de granulação fina com o mapeamento de propriedades mais ou menos diretamente ao widget UI underlaying. 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 classe Presenter vai falar com o modelo e "mapa" para a vista. Esta abordagem é chamada de "Ver passiva". A vantagem é que a vista é fácil de testar, e é mais fácil de se mover entre as plataformas de interface do usuário (Web, Windows / XAML, etc.). A desvantagem é que você não pode aproveitar coisas como ligação de dados (que é realmente poderosa em frameworks como WPF e Silverlight ).

A segunda sabor de MVP é o controlador de supervisão. Nesse caso o seu Visão pode ter uma propriedade chamada do cliente, que, em seguida, novamente é vinculação de dados para os widgets de interface do usuário. Você não tem que pensar sobre a sincronização e micro-gerenciar a vista, e o controlador de Supervisão pode intervir e ajudar quando necessário, por exemplo, com lógica de interação compled.

O terceiro "sabor" de MVP (ou alguém talvez chamá-lo um padrão separado) é o modelo de apresentação (ou por vezes referido Model-View-ViewModel). Comparado com o MVP você "mesclar" o H eo P em uma classe. Você tem o seu objeto cliente que seus widgets de interface do usuário é ligado a dados, mas você também tem campos adicionais UI-spesific como "IsButtonEnabled", ou "IsReadOnly", etc.

Eu acho que o melhor recurso que eu encontrei para arquitetura de interface do usuário é a série de posts feitos por Jeremy Miller sobre a O construir a sua própria tabela da Série CAB de Conteúdos . Ele cobriu todos os sabores de MVP e mostrou código C # para implementá-las.

Eu também tenho um blog sobre o padrão Model-View-ViewModel no contexto do Silverlight em cima da YouCard Re-visitados: Implementando o padrão de ViewModel .

Respondeu 08/08/2008 em 06:55
fonte usuário

votos
31
  • MVP = Model-View-Presenter
  • MVC = MVC

    1. Ambos os padrões de apresentação. Eles separam as dependências entre um Modelo (pense objetos de Domínio), sua página de tela / web (a vista), e como sua interface é suposto comportar (Apresentador / Controller)
    2. Eles são bastante semelhantes em termos de conceito, gente inicializar o Apresentador / Controlador de forma diferente dependendo do gosto.
    3. Um grande artigo sobre as diferenças é aqui . O mais notável é que MVC padrão tem o Modelo de atualizar o View.
Respondeu 05/08/2008 em 11:22
fonte usuário

votos
15

Ambas estas estruturas têm como objectivo separar preocupações - por exemplo, a interação com uma fonte de dados (modelo), a lógica da aplicação (ou transformando esses dados em informações úteis) (Controller / apresentador) 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 mais elevado também. Um bom exemplo disso é o projeto MVC Storefront .

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

A distinção feita é que em um aplicativo MVC tradicionalmente tem a vista eo controlador de interagir com o modelo, mas não com os outros.

projetos MVP têm o Presenter acessar o modelo e interagir com a vista.

Dito isto, ASP.NET MVC é por estas definições um quadro MVP porque o controlador acessa o modelo para preencher a vista que se destina a ter nenhuma lógica (apenas exibe as variáveis ​​fornecidas pelo controlador).

Para obter talvez uma idéia da distinção ASP.NET MVC de MVP, veja esta apresentação MIX por Scott Hanselman.

Respondeu 05/08/2008 em 11:20
fonte usuário

votos
12

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

Arquitetonicamente, MVP é Controller Page abordagem baseada em MVC é Front Controller abordagem baseada. Isso significa que no MVP ciclo padrão página de formulário web vida é apenas reforçada por extrair a lógica de negócios a partir do código por trás. Em outras palavras, a página está o pedido http uma manutenção. Em outras palavras, o MVP IMHO é forma evolutiva teia tipo de acessório. MVC no outro lado muda completamente o jogo porque o pedido fica interceptado por classe de controlador antes de página é carregada, a lógica do negócio é executada lá e, em seguida, com o resultado final do controlador de processamento dos dados apenas objecto de dumping para a página ( "vista") Em que sentido, olhares MVC (pelo menos para mim) muito a Supervisão sabor Controlador de MVP reforçada com mecanismo de roteamento

Ambos permitem TDD e têm desvantagens e upsides.

Decisão sobre como escolher um deles IMHO deve ser baseado em quanto tempo uma investido em ASP NET tipo de formulário web de desenvolvimento web. Se alguém se consideraria boa nos formulários Web, gostaria de sugerir MVP. Se alguém não se sentir tão confortável em coisas tais como o ciclo de vida da página etc MVC poderia ser um caminho a percorrer aqui.

Aqui está mais um elo blog dando um pouco mais detalhes sobre este tema

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

Respondeu 21/09/2008 em 13:32
fonte usuário

votos
11

Cada um deles aborda problemas diferentes e pode até mesmo ser combinados em conjunto para ter algo como abaixo

O padrão combinado

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

Respondeu 13/03/2017 em 05:54
fonte usuário

votos
9

Algo que eu não entendo é por que a vinculação de dados tem de reduzir a capacidade de teste. Quer dizer, uma visão é efetivamente baseado fora do que poderia ser pensado como uma ou mais visualizações de banco de dados, certo? Pode haver conexões entre linhas em diferentes pontos de vista. Alternativamente, podemos falar em vez de relacional orientada a objetos, mas que na verdade não muda nada - ainda temos uma ou mais distintas entidades de dados.

Se vemos a programação como estruturas de dados algoritmos +, então não seria melhor ter as estruturas de dados explícito quanto possível, e, em seguida, desenvolver algoritmos que cada dependem tão pequeno um pedaço de dados possível, com acoplamento mínimo entre os algoritmos ?

Sinto padrões de pensamento FactoryFactoryFactory muito Java-esque aqui - nós queremos ter múltiplas visões, modelos múltiplos, múltiplos graus de liberdade em todo o lugar. É quase como que é a força motriz por trás do MVC e MVP e outros enfeites. Agora deixe-me perguntar o seguinte: quantas vezes é o custo que você paga por isso (e há mais definitivamente é um custo) vale a pena?

Eu também não vejo nenhuma discussão de como gerenciar com eficiência o estado entre solicitações HTTP. Não temos aprendido com as pessoas funcionais (e os erros volumosas feitas por spaghetti imperativas) que o estado é mau e deve ser minimizado (e quando usado, deve ser bem entendido)?

Eu vejo um monte de uso dos termos MVC e MVP sem muita evidência de que as pessoas pensam criticamente sobre eles. Claramente, o problema é "eles", me, ou ambos ...

Respondeu 28/01/2009 em 22:11
fonte usuário

votos
8

Há muitas respostas para a pergunta, mas eu senti que há uma necessidade de alguma resposta muito simples comparando claramente os dois. Aqui está a discussão que eu inventei quando um usuário procura por um nome do filme em um aplicativo MVP e MVC:

Usuário: Clique, clique ...

Ver : Quem é esse? [ MVP | MVC ]

Usuário: Eu só clicar no botão de pesquisa ...

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

( Ver chamando o apresentador | Controlador ...) [ MVP | MVC ]

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

Apresentador | Controlador : Ei Ver , há qualquer 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 | Controlador está chamando o modelo ...) [ MVP | MVC ]

Apresentador | Controlador : Ei Modelo , Você tem qualquer correspondência para este termo de busca ?: “piano” [ MVP | MVC ]

Modelo : Ei Apresentador | Controlador , deixe-me ver ... [ MVP | MVC ]

( Modelo está fazendo uma consulta ao banco de dados filme ...) [ MVP | MVC ]

( Depois de um tempo ... )

-------------- Este é o lugar onde MVP e MVC começar a divergir ---------------

Modelo : Eu encontrei uma lista para você, Apresentador , aqui está em JSON “[{ "name": "Professora de Piano", "ano": 2001}, { "name": "Piano", "ano": 1993} ]”[ MVP ]

Modelo : Há algum resultado disponível, Controlador . Eu criei uma variável de campo no meu exemplo e encheu-o com o resultado. Seu nome é "searchResultsList" [ MVC ]

( Apresentador | Controlador graças Modelo e recebe de volta à exibição ) [ MVP | MVC ]

Apresentador : Obrigado pela espera Ver , eu encontrei uma lista de resultados para você combinar e arranjou-los em um formato apresentável: [ "Professora de Piano 2001", "Piano 1993"]. Por favor, mostrá-lo para o usuário em uma lista vertical. Também por favor, ocultar a barra de progresso agora [ MVP ]

Controlador : Obrigado pela espera Ver , pedi Modelo sobre a sua consulta de pesquisa. Ele diz ter encontrado uma lista de resultados correspondentes e armazenados-los em uma variável chamada "searchResultsList" dentro de sua instância. Você pode obtê-lo de lá. Também por favor, ocultar a barra de progresso agora [ MVC ]

Ver : Muito obrigado Presenter [ MVP ]

Ver : Obrigado "Controller" [ MVC ] (Agora, a vista está questionando-se: Como devo apresentar os resultados que recebo do Modelo ? Para o usuário Se o ano de produção do filme a chegar primeiro ou último ... deveria? estar em uma lista vertical ou horizontal? ...)

No caso você está interessado, eu tenho escrito uma série de artigos sobre padrões de arquitetura de aplicativos (MVC, MVP, MVVP, arquitetura limpa, ...) acompanhado por um repo Github aqui . Mesmo que a amostra é escrito para android, os princípios subjacentes pode ser aplicado a qualquer forma.

Respondeu 06/04/2018 em 13:51
fonte usuário

votos
8

Em android há versão do MVC que é mvp: Qual é MVP?

O padrão MVP permite separar a camada de apresentação da lógica, para que tudo sobre como a interface funciona é separado da forma como representá-lo na tela. Idealmente, o padrão MVP iria conseguir a mesma lógica pode ter pontos de vista completamente diferentes e intercambiáveis.

A primeira coisa a esclarecer é que MVP não é um padrão de arquitetura, é apenas responsável pela camada de apresentação. Em qualquer caso, é sempre melhor para usá-lo para sua arquitetura que não usá-lo em tudo.

Um exemplo para MVP é https://github.com/antoniolg/androidmvp

O que é MVC? MVC arquitetura é um dos mais antigos padrões disponíveis para alcançar a separação de preocupações. MVC consiste em três camadas, a saber, Modelo, Vista e Controlador.

Clássico MVC existia no momento em que cada controle / gadget que existia na tela foi considerado mudo e cada controle é emparelhado com o seu próprio controlador para gerenciar as interações do usuário acontecendo sobre eles. Então, se existem 10 gadgets, em seguida, 10 controladores têm de existir. Neste cenário, todos os gadgets é contado como uma visão. O advento de sistemas de GUI do Windows mudou esse quadro. A relação de Controle-controlador se tornou obsoleto. Controls ganhou a inteligência para responder às ações iniciadas pelo usuário. No mundo Windows, vista é uma superfície na qual existem todos os controles / gadgets, portanto, há uma necessidade de apenas um controlador. View pode receber eventos e chegar para controladores de ajudar a fazer mais processamento.

Exemplo de código para MVC no android http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

Diferença entre ambos está disponível aqui http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Agora Da minha experiência você deve usar MVP para o projeto android base, porque melhorada versão do MVC Model.

Respondeu 02/07/2016 em 07:15
fonte usuário

votos
8

Eu tenho usado tanto MVP e MVC e embora nós como desenvolvedores tendem a se concentrar sobre as diferenças técnicas de ambos os padrões do ponto de MVP em IMHO está muito mais relacionada à facilidade de adoção que qualquer outra coisa.

Se eu estou trabalhando em uma equipe que já como uma boa base em formulários web estilo de desenvolvimento é muito mais fácil para introduzir MVP do MVC. Eu diria que MVP neste cenário é uma vitória rápida.

Minha experiência me diz que a mudança de uma equipe de formulários web para MVP e depois de MVP para MVC é relativamente fácil; movendo-se de formulários web para MVC é mais difícil.

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

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

Respondeu 02/01/2009 em 11:35
fonte usuário

votos
7

Em MVP a vista extrai dados do apresentador, que desenha e prepara / normaliza os dados do modelo, enquanto no MVC o controlador chama os dados do modelo e fixado, por impulso no modo de exibição.

Em MVP você pode ter uma visão única trabalhar com vários tipos de apresentadores e um único apresentador trabalhando com diferentes visões múltiplas.

MVP geralmente usa algum tipo de um quadro vinculativo, como o quadro vinculativo Microsoft WPF ou vários quadros de ligação para HTML5 e Java.

Nesses enquadramentos, o UI / HTML5 / XAML, está ciente do que propriedade do apresentador cada UI elemento é exibido, então quando você ligar o objectivo de um apresentador, a vista parece para as propriedades e sabe como desenhar dados a partir deles e como configurá-los quando um valor é alterado na interface do usuário pelo usuário.

Assim, se, por exemplo, o modelo é um carro, em seguida, o apresentador é algum tipo de um apresentador carro, expõe as propriedades do carro (ano, fabricante, bancos, etc.) para a vista. A visão sabe que o campo de texto chamado 'montadora' precisa exibir a propriedade apresentador Maker.

Você pode então ligar-se à vista muitos tipos diferentes de apresentador, todos devem ter propriedade Maker - que pode ser de um avião, comboio ou o que nunca, a vista não se importa. A visão chama dados do apresentador - não importa qual - desde que implementa uma interface concordou.

Este quadro vinculativo, se você tira-lo para baixo, é, na verdade, o :-) controlador

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

MVC é grande, mas o problema é que, geralmente, seu controlador per view. Controlador A sabe como definir campos de visão A. Se agora, você quer View A para exibir dados do modelo B, você precisa controlador A saber modelo B, ou você precisa de controlador A para receber um objeto com uma interface - que é como MVP só que sem as ligações, ou você precisa reescrever o código conjunto UI no controlador B.

Conclusão - MVP e MVC são ambos dissociar de padrões de interface do usuário, mas MVP geralmente usa um quadro ligações que é MVC por baixo. ASSIM MVP está em um nível de arquitetura maior do que MVC e um padrão de embalagem acima da MVC.

Respondeu 07/06/2013 em 22:16
fonte usuário

votos
6

Minha curta vista humilde: MVP é para grandes escalas, e MVC para pequenas escalas. Com MVC, eu algum dia sentir o V eo C pode ser visto de duas faces de um único componente indivisível sim directamente ligado a M, e um inevitavelmente cai para isso quando vai para baixo-a escalas mais curtas, como controles de UI e widgets de base. A este nível de granularidade, MVP faz pouco sentido. Quando se pelo contrário ir para escalas maiores, interface apropriada se torna mais importante, o mesmo com atribuição inequívoca de responsabilidades, e aqui vem MVP.

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

Respondeu 20/02/2013 em 17:55
fonte usuário

votos
5

MVC

MVC é um padrão para a arquitetura de um aplicativo de software. Ele separar a lógica da aplicação em três partes distintas, promovendo modularidade e facilidade de colaboração e reutilização. É também torna as aplicações mais flexível e de boas-vindas para iterations.It separa uma aplicação para os seguintes componentes:

  • Modelos para manipulação de dados e lógica de negócios
  • Controladores para manusear o interface de utilizador e aplicação
  • Vistas para a manipulação de objetos de interface gráfica do usuário e apresentação

Para tornar isto um pouco mais claro, vamos imaginar um aplicativo simples lista de compras. Tudo o que queremos é uma lista do nome, quantidade e preço de cada item que precisamos comprar esta semana. Abaixo iremos descrever como poderíamos implementar alguns dos essa funcionalidade usando MVC.

digite descrição da imagem aqui

Model-View-Presenter

  • O modelo é o de dados que vai ser exibido na vista de (interface do utilizador).
  • A vista é uma interface que exibe dados (modelo) e comandos de rotas de utilizador (eventos) para o apresentador de agir sobre esses dados. O ponto de vista geralmente tem uma referência ao seu apresentador.
  • O Presenter é o “meio-homem” (interpretado pelo controlador no MVC) e tem referências a ambos, vista e modelo. Por favor, note que a palavra “Modelo” é enganosa. Deve sim ser lógica de negócios que recupera ou manipula um modelo . Por exemplo: Se você tem um banco de dados armazenar usuário em uma tabela de banco de dados e sua exibição quer exibir uma lista de usuários, em seguida, o apresentador teria uma referência à sua lógica de negócios de banco de dados (como um DAO) de onde o Presenter irá consultar uma lista de usuários.

Se você quiser ver uma amostra de simples implementação verifique esta pós github

Um fluxo de trabalho concreto de consultar e exibir uma lista de usuários a partir de um banco de dados poderia funcionar assim: digite descrição da imagem aqui

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

Pattern MVC

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

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

Padrão MVP

  • Ver é mais fracamente acoplada ao modelo. O apresentador é responsável pela ligação do modelo à vista.

  • Mais fácil de teste de unidade porque a interacção com a visualização é por meio de uma interface

  • Normalmente visualizar a mapa apresentador 1-1. visualizações complexas podem ter múltiplos apresentadores.

Respondeu 29/11/2017 em 10:14
fonte usuário

votos
3

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

Esta palestra Droidcon NYC 2017 - projeto aplicativo Limpe com componentes da arquitetura esclarece que

digite descrição da imagem aqui digite descrição da imagem aqui

Respondeu 09/09/2015 em 02:34
fonte usuário

votos
0

Eu acho que esta imagem por Erwin Vandervalk (e do acompanhante artigo ) é a melhor explicação para MVC, MVP, e MVVM, suas semelhanças e suas diferenças. O artigo não aparecer em resultados de pesquisas 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 coincide com o que o tio Bob Martin disse em seu uma de suas palestras: que MVC foi originalmente concebido para os pequenos componentes de interface do usuário, e não para a arquitetura do sistema)

Respondeu 10/05/2019 em 04:43
fonte usuário

votos
0

este vídeo agradável do Tio Bob onde ele explica brevemente MVC e MVP no final.

O que eu acho é MVP é uma versão melhorada do MVC onde você basicamente separar a preocupação de como você vai mostrar os dados que você tem. Apresentador inclui meio a lógica de negócios de sua interface do usuário e fala através de uma interface que torna mais fácil para testar a sua lógica de negócios UI através de diferentes pontos de vista. MVC ainda fala através de interfaces (limites) para camadas de cola mas não tem essa restrição para impor a lógica de apresentação UI. Fora isso, eu realmente não vejo nenhum mais diferenças.

Respondeu 25/01/2018 em 21:24
fonte usuário

votos
0

MVP

MVP significa Model - Ver- Presenter. Isto veio a imaginar no início de 2007, onde a Microsoft introduziu aplicativos do Windows Smart Client.

Apresentador está agindo como uma função de supervisão MVP cuja ligação Ver eventos e lógica de negócio a partir de modelos.

Ver evento de ligação será implementado em Presenter a partir de uma interface de visualização.

Ver é o iniciador para entradas do usuário e então delega os eventos para Presenter e apresentador lida com ligações de eventos e obter dados de modelos.

Prós: View está tendo apenas UI não quaisquer lógicas Alto nível de testabilidade

Contras: pouco complexo e mais trabalho quando execução ligações de eventos

MVC

MVC significa Model-View-Controller. Controlador é responsável por criar modelos e renderização vistas com modelos de ligação.

Controlador é o iniciador e decide que ver para renderizar.

Prós: ênfase na responsabilidade único princípio Alto nível de testabilidade

Contras: Às vezes demasiado a carga de trabalho para controladores, se tentam tornar múltiplas visões em mesmo controlador.

Respondeu 12/01/2016 em 04:50
fonte usuário

votos
-1
  • No MVC, Vista tem a parte da interface do usuário, o controlador é o mediador entre a visão e modelo modelo contém a lógica de negócios.
  • No MVP, Vista contém UI e implementação do apresentador já que aqui o apresentador é apenas uma interface modelo é o mesmo ou seja, contém lógica de negócios.
Respondeu 09/09/2019 em 22:31
fonte usuário

votos
-1

A resposta mais simples é como a visão interage com o modelo. Em MVP o modelo está vinculado ao apresentador, que é responsável por atualizar a vista. Em MVC o modelo atualiza a vista diretamente.

Respondeu 16/11/2017 em 17:32
fonte usuário

votos
-2

Aqui postei acima é um somatório de fracasso e incapacidade do homem para entender o aperto de mão mais simples entre duas máquinas. Vou explicar usando o bom senso para tentar acordá-lo todo acima destes idealismo de delirante que têm encontrado o seu caminho para as mentes daqueles que desejam criá-los. E tão tolo quanto todos estes processos soar, verdade é o Object Model (que é o arquivo HTML) é solicitada pela máquina cliente. Aqui está como tudo se resume.

  1. Um Hyperlink é pressionada e um único pedido é enviado pela máquina do cliente para o servidor. O servidor responde a esse pedido com uma resposta enviando o modelo de objeto para o cliente. (Conhecido simplesmente como uma "resposta").
  2. O servidor responde enviando um modelo de objeto (o arquivo HTML) para a Máquina de Clientes (Conhecido como um aperto de mão cheia).
  3. O Navegador Os clientes podem agora rende o "View" ao analisar, lexing / tokenizing, e converter esse Object Model Markup em uma GUI "View".

Eu posso estar aposentado agora, mas por Puxa vocês aqui estão discutindo e debatendo um total absurdo. E honestamente, não importa o que você chama um aperto de mão entre duas máquinas não pode ser qualquer coisa fora de um único pedido, uma única resposta do "Modelo" Objeto e, finalmente, o navegador de Clientes Renderização o "View".

E para encerrar, uma vista não existe em um aperto de mão. O modelo de objeto é apenas uma marcação para o navegador de se converter ao GUI widget sets e Métodos Eval por três ou mais modelos de objeto. HTML, CSS e JavaScript. E não importa o quanto alguém pode dizer que um servidor faz algo fora do comum é cavalo Dung.

O "Servidor" não é o "controlador" é uma directer e só dirige a resposta enviando um objeto de resposta "Modelo". Navegador do cliente (que seria o controlador provável), então, cria o "View" do "Modelo" Objeto do Servidor não tem nada a ver com isso. Sua linguagem de computador não pode entrar no modelo de objeto em tudo nem delegá-la. Tudo o que é um Criador Markup.

toda a confusão é simplesmente um navegador do lado do cliente "Controller", que analisa o "Modelo" para tornar o "View" ou CMV ou MCV (enviada como Modelo em primeira ordem) e você não pode mudá-lo. Mas você pode chamá-lo simplesmente uma solicitação, Object Model Resposta e renderização Ver ou RRMV.

Respondeu 31/12/2018 em 02:10
fonte usuário

votos
-2

Muita gente não sabe exatamente o que é a diferença entre o controlador e Presenter no MVC e MVP respectivamente.

é uma equação simples onde

MVC View = Visualizar e Apresentador de MVP

MVP = Modelo controlador e Modelo de MVC

mais informações consulte esta http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html

Respondeu 31/07/2017 em 10:13
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more