Qual é a diferença entre MVC e MVVM?

Acho que a maneira mais fácil de entender o que estes acrónimos devem significar é esquecê-los por um momento. Em vez disso, pense no software com o qual eles se originaram, cada um deles. Ele realmente resume-se apenas à diferença entre a web inicial e o desktop. O primeiro acrónimo, MVC, surgiu na web. (Sim, ele pode ter estado lá antes, mas a web é como ele foi popularizado para as massas de Web developers.) Think database, HTML pages, and code no meio. Vamos refinar isso apenas um pouco para chegar ao MVC: para "banco de dados", vamos assumir banco de dados mais código de interface. Para "páginas HTML", vamos assumir modelos HTML Mais código de processamento de modelo. Para" code in between", vamos assumir que o mapeamento de código cliques de usuário para ações, possivelmente afetando o banco de dados, definitivamente fazendo com que outra Vista seja exibida. É isso, pelo menos para efeitos desta comparação. Vamos reter uma característica desta coisa da web, não como é hoje, mas como é existia há dez anos, quando Javascript era um aborrecimento desprezível, o que os programadores reais fizeram bem em se afastar: a página HTML é essencialmente burra e passiva. O navegador é um cliente fino, ou se você quiser, um cliente pobre. Não há inteligência no navegador. Os carregamentos de página inteira são a regra. A" vista " é gerada de novo cada vez. Lembremo-nos de que esta forma web, apesar de estar na moda, era horrivelmente retrógrada em comparação com a área de trabalho. Aplicações de secretária são clientes gordos, ou clientes ricos, se preferir. (Mesmo um programa como o Microsoft Word pode ser pensado como um tipo de cliente, um cliente para documentos.) São clientes cheios de inteligência, cheios de conhecimento sobre seus dados. Eles têm estatuto. Eles guardam dados que estão a tratar em memória. Nada de tretas como uma recarga de página inteira.

E esta forma de trabalho rica é provavelmente a origem do segundo acrónimo, MVVM. Não se deixe enganar pelas cartas, pela omissão dos controladores C. ainda estão lá. Têm de ser. Nada é removido. Nós apenas adicionamos uma coisa: status, dados Cache sobre o cliente (e junto com a inteligência de TI para lidar com esses dados). Esses dados, essencialmente um cache no cliente, agora é chamado de "ViewModel". É o que permite uma interactividade Rica. E é isso.

[[12]}MVC = model, controller, view = essentially one-way communication = poor interactivity
• MVVM = model, controller, cache, view = two-way communication = rich interactivity

Podemos ver que com Flash, Silverlight, e - mais importante-Javascript, a web abraçou MVVM. Os navegadores já não podem ser legitimamente chamados de clientes magros. Olha para a programabilidade deles. Olha para o consumo de memória deles. Veja toda a interatividade Javascript em páginas web modernas. Pessoalmente, acho esta teoria e acrónimos negócios mais fáceis de entender olhando para o que se refere na realidade concreta. Conceitos abstratos são úteis, especialmente quando demonstrados em concreto matéria, para que a compreensão possa completar o círculo.

 

MVVM Model-View View Model é semelhante ao MVC, Controlador Model-View

O controlador é substituído por um ViewModel. O ViewModel fica por baixo da camada UI. O ViewModel expõe os objetos de dados e comandos de que a vista necessita. Você pode pensar nisso como um objeto container que a view vai buscar seus dados e ações. A ViewModel puxa seus dados do modelo.

Russel East faz um blog discutir mais em detalhe porque é que a MVVM é diferente da MVC

[[1]}para uma coisa, MVVM é uma progressão do padrão MVC que usa XAML para lidar com o display. Este artigo descreve algumas das facetas dos dois.

O impulso principal da arquitetura modelo/View/View Model parece ser que em cima dos dados ("o modelo"), há outra camada de componentes não-visuais ("o modelo") que mapeiam os conceitos dos dados de forma mais próxima aos conceitos da visão dos dados ("a visão"). É o modelo que a vista liga-se ao modelo, não directamente.

Você pode ver uma explicação do padrão MVVM no ambiente do Windows:

No modelo-Ver-Ver modelo, um aplicativo é composto por três componentes gerais.

• Modelo : isto representa o modelo de dados que o seu aplicativo consome. Por exemplo, em um aplicativo de compartilhamento de imagens, Esta camada pode representar o conjunto de imagens disponíveis em um dispositivo e a API usada para ler e escrever para a imagem biblioteca.

• View : um aplicativo normalmente é composto por várias páginas de UI. Cada página mostrada ao usuário é uma vista na terminologia MVVM. A vista é o código XAML usado para definir e estilo o que o usuário vê. Os dados do modelo são exibidos para o Usuário, e é o trabalho do ViewModel para alimentar a IU estes dados com base no estado atual do aplicativo. Por exemplo, em um aplicativo de compartilhamento de imagens, as vistas seriam a interface que mostra ao usuário a lista de álbuns no dispositivo, as fotos em um álbum, e talvez outro que mostra ao usuário uma imagem particular.

• ViewModel : o ViewModel liga o modelo de dados, ou simplesmente o modelo, à UI, ou vistas, da aplicação. Ele contém a lógica com a qual gerenciar os dados do modelo e expõe os dados como um conjunto de propriedades às quais a interface XAML, ou vistas, pode se ligar. Por exemplo, em um aplicativo de compartilhamento de imagens, O View Model iria expor uma lista de álbuns, e para cada álbum expor uma lista de imagem. A IU é agnóstica de onde as imagens vêm e como elas são recuperadas. Ele simplesmente sabe de um conjunto de imagens como exposto pelo View Model e mostra-os para o usuário.

Eu pensei que uma das principais diferenças era que em MVC, o seu V lê o seu M diretamente, e vai através do C para manipular os dados, enquanto em MVVM, o seu VM atua como um proxy M, bem como fornecer a funcionalidade disponível para você V.

Se Eu não estou cheio de lixo, estou surpreso que ninguém criou um híbrido, onde o seu VM é apenas um proxy M, E C fornece toda a funcionalidade.

MVVM é um refinamento (discutível) do modelo de apresentação padrão. Eu digo discutível, porque a única diferença é como WPF fornece a capacidade de fazer a ligação de dados e manuseio de comandos.

Diferença simples: (inspirada pelo curso de Yaakov em AngularJS)

MVC (Controlador De Vista do Modelo)

1. modelos: modelos contêm informação de dados. Não invoca ou usa Controller e View. Contém a lógica de negócio e formas de representar dados. Alguns destes dados, de alguma forma, podem ser exibidos na vista. Ele também pode conter lógica para recuperar os dados de alguma fonte.
2. controlador: actua como a ligação entre vista e modelo. View calls Controller and Controller calls the model. Basicamente informa o modelo e / ou a vista para mudar conforme apropriado.
3. Ver: trata da parte IU. Interage com o utilizador.

MVVM (Model View View Model Model)

ViewModel:

1. é a representação do estado da vista.
Contém os dados que são mostrados na vista.
2. responde à vista eventos, ou seja, lógica de apresentação.
3. chama outras funcionalidades para processamento lógico de empresas.
4. nunca pede directamente à vista para mostrar nada.

O modelo de visualização é um modelo "abstracto" para os seus elementos de interface do utilizador. Ele deve permitir que você execute os comandos, e ações em sua visão de uma forma não-visual (por exemplo, para testá-lo).

Se trabalhou com o MVC, provavelmente encontrou alguma utilidade para criar objectos de modelos que reflictam o estado da sua vista, por exemplo, para mostrar e esconder alguma janela de edição, etc. Nesse caso, você está usando um modelo de visualização.

O padrão MVVM é simplesmente a generalização desse praticar para todos os elementos da IU.

E não é um padrão Microsoft, o que se adiciona é que as ligações de dados WPF / Silverlight são especialmente adequadas para trabalhar com este padrão. Mas nada o impede de usá-lo com caras de servidor java, por exemplo.

MVC é um ambiente controlado e MVVM é um ambiente reativo.

Em um ambiente controlado você deve ter menos código e uma fonte comum de lógica; que deve sempre viver dentro do controlador. No entanto, no mundo web MVC facilmente se divide em ver lógica de criação e ver lógica dinâmica. A criação vive no servidor e a dinâmica vive no cliente. Você vê isso muito com ASP.NET MVC combinado com AngularJS, enquanto o servidor irá criar uma vista e passar um modelo e enviá-lo para o cliente. O cliente irá então interagir com a vista em que caso AngularJS entra como um controlador local. Uma vez submetido o modelo ou um novo modelo é passado de volta para o controlador do servidor e tratado. (Assim o ciclo continua e há um monte de outras traduções deste manuseio ao trabalhar com sockets ou AJAX etc, mas sobre toda a arquitetura é idêntica.)

MVVM é um ambiente reactivo, o que significa que normalmente se escreve código (como por exemplo: gatilhos) que serão ativados com base em algum evento. Em XAML, onde MVVM prospera, tudo isso é facilmente feito com o framework de databinding construído em bases de dados, mas como mencionado isso vai funcionar em qualquer sistema em qualquer visão com qualquer linguagem de programação. Não é específico da em. O ViewModel dispara (normalmente um evento de alteração de propriedade) e a View reage a ele com base no que quer que desencadeie a sua criação. Isto pode ficar técnico, mas a conclusão é que a visão é sem estado e sem lógica. Simplesmente muda de Estado em valores. Além disso, os modelos de visão são apátridas com muito pouca lógica, e os modelos são o estado com essencialmente lógica Zero, pois eles só devem manter o estado. Eu descrevo isto como estado de Aplicação (Modelo), tradutor de Estado (ViewModel), e então o estado visual / interação (ver).

Numa aplicação MVC desktop ou cliente, deve ter um modelo e o modelo deve ser usado pelo controlador. Com base no modelo, O controlador irá modificar a vista. As vistas estão normalmente ligadas para controladores com Interfaces para que o controlador possa trabalhar com uma variedade de vistas. Em ASP.NET a lógica para MVC é um pouco para trás no servidor como o controlador gerencia os modelos e passa os modelos para uma visão selecionada. A vista é então preenchida com dados baseados no modelo e tem sua própria lógica (geralmente outro conjunto de MVC, como feito com AngularJS). As pessoas vão discutir e ficar confuso com a aplicação MVC e tentar fazer ambos em que ponto a manutenção do projeto vai acabou por se tornar um desastre. Sempre colocar a lógica e controle em um único local ao usar MVC. Não escreva lógica de vista no código atrás da vista (ou na vista via JS para web) para acomodar dados do controlador ou modelo. Deixe o controlador mudar a vista. A única lógica que deve viver em uma vista é o que for preciso para criar e executar através da Interface que está usando. Um exemplo disso é enviar um nome de usuário e senha. Se o ecrã ou página web (no cliente) O controlador deve lidar com o processo de Submissão sempre que a vista dispara a ação de Submissão. Se for feito corretamente, você pode sempre encontrar o seu caminho em torno de uma web MVC ou aplicação local facilmente.

MVVM é pessoalmente o meu favorito por ser completamente reativo. Se um modelo muda estado o View Model ouve e traduz esse estado e é isso!!! A vista está, então, ouvindo o ViewModel para mudança de estado e também atualiza com base na tradução do ViewModel. Algumas pessoas chamam-lhe MVVM puro, mas há realmente apenas um e não me interessa como o argumentas e é sempre MVVM puro onde a vista não contém absolutamente nenhuma lógica. [[1]} Aqui está um pequeno exemplo: digamos que você quer ter um menu deslizando em um botão pressione. Em MVC você terá uma ação MenuPressed em sua interface. O controlador saberá quando você clicar no botão do Menu e, em seguida, dizer à vista para deslizar no Menu com base em outro método de Interface, como SlideMenuIn. Uma viagem de ida e volta por que razão? Aumenta a decisão do controlador não podes ou queres fazer outra coisa em vez disso, é por isso. O controlador deve ser responsável pela vista com a vista não fazendo nada a menos que o controlador o diga. No entanto, em MVVM o menu slide em animação deve ser construído dentro e genérico e em vez de ser dito para deslizá-lo dentro irá fazê-lo com base em algum valor. Então ele ouve o modelo e quando o modelo diz, IsMenuActive = true ( ou no entanto) a animação para isso acontece. Agora, com isso dito eu quero fazer outro ponto Muito claro e, por favor, prestem atenção. IsMenuActive é provavelmente um mau design MVVM ou modelo de visualização. Ao projetar um ViewModel você nunca deve assumir que uma View terá quaisquer recursos e apenas passar o estado do modelo traduzido. Dessa forma, se você decidir mudar a sua vista para remover o Menu e apenas mostrar os dados / Opções de outra forma, o ViewModel não se importa. Então, como você geriria o Menu? Quando os dados fazem sentido, é assim. Então, uma maneira de fazer isso é dar ao Menu uma lista de opções (provavelmente um conjunto de modelos internos). Se essa lista tem dados, o Menu então sabe abrir através do gatilho, se não, então ele sabe se esconder através do gatilho. Você simplesmente tem dados para o menu ou não no ViewModel. Não decida mostrar / esconder esses dados no modelo de visualização.. simplesmente traduza o estado do modelo. Desta forma, a visão é completamente reativa e genérica e pode ser usada em muitas situações diferentes. Tudo isto provavelmente não faz qualquer sentido se já não estiveres. pelo menos um pouco familiarizado com a arquitetura de cada um e aprender Pode ser muito confuso como você vai encontrar um monte de informações ruins na rede. Então..... coisas a ter em mente para fazer isto bem. Decida de frente como projetar sua aplicação e se ater a ela.

Se você faz MVC, o que é ótimo, então certifique-se que o controlador é controlável e em total controle de sua visão. Se você tem uma visão grande considere adicionar controles à vista que tem diferentes controladores. APENAS Não coloque esses controladores em cascata para diferentes controladores. Muito frustrante de manter. Tome um momento e projetar as coisas separadamente de uma forma que funcionará como componentes separados... E deixar sempre o controlador dizer ao modelo para commit ou persistir armazenamento. A configuração de dependência ideal para MVC in é ver Controller Controller → Model ou com ASP.NET (don't get me started) Model ← View ↔ Controller → Model (where Model can be the same or a totally different Model from Controller to Ver) ...é claro que a única necessidade de saber do controlador em vista neste ponto é principalmente para a referência do endpoint para saber onde voltar a passar um modelo.

Se fizeres MVM, eu abençoo a tua alma bondosa, mas aproveita o tempo para o fazeres bem! Não use interfaces para um. Deixe sua visão decidir como ele vai parecer baseado em valores. Jogar com a vista com dados Mock. Se você acabar tendo uma vista que está lhe mostrando um Menu (como por exemplo), mesmo que você não queria isso no momento, então bom. A tua visão está a funcionar como devia e a reagir com base nos valores como devia. Basta adicionar mais alguns requisitos ao seu gatilho para se certificar de que isso não acontece quando o ViewModel está em um determinado estado traduzido ou comando o ViewModel para esvaziar este estado. Em seu ViewModel não remova isso com lógica interna, como se você estivesse decidindo a partir de lá se a visão deve ou não vê-lo. Lembre-se que você não pode assumir que há um menu ou não no ViewModel. E finalmente, o modelo deve apenas permitir que você mude e o estado mais provável da loja. É aqui que a validação e tudo irá ocorrer; por exemplo, se o modelo não puder modificar o estado, então ele simplesmente marcará a si mesmo como sujo ou algo assim. Quando o ViewModel perceber isso ele vai traduzir o que é sujo, e a vista vai então perceber isso e mostrar alguma informação através de outro gatilho. Todos os dados na vista podem ser ligados ao View Model para que tudo possa ser dinâmico apenas o modelo e o View Model não tem absolutamente nenhuma idéia sobre como a vista vai reagir ao vinculativo. Na verdade, o modelo também não faz ideia de um modelo de vista. Ao configurar dependências, elas devem apontar assim e somente assim ver → View Model → Model (e uma nota lateral aqui... e isto também vai ser discutido, mas não me interessa... Não passe o modelo para a vista. A vista não deve ver um período Modelo. Eu dou a um rato o que você viu ou como você fez, isso é errado.) Aqui está a minha última dica... Olhe para uma aplicação MVC bem projetada, mas muito simples, e faça o mesmo para uma aplicação MVVM. Um terá mais controle com flexibilidade limitada a zero, enquanto o outro não terá controle e flexibilidade ilimitada.

Um ambiente controlado é bom para gerir toda a aplicação a partir de um conjunto de controladores ou (uma única fonte), enquanto um ambiente reactivo pode ser dividido em repositórios separados sem absolutamente nenhuma ideia do que o resto da aplicação está a fazer. Micro-gestão vs gestão livre.

Se não te confundi o suficiente, tenta contactar-me... Não me importo de rever isto em detalhes com ilustrações e exemplos. No final do dia somos todos programadores e com essa anarquia vive dentro de nós quando codifica... As regras vão ser quebradas, as teorias vão mudar, e tudo isto vai acabar como uma lavagem de porcos... Mas ao trabalhar em grandes projetos e em grandes equipes, realmente ajuda a chegar a acordo sobre um padrão de design e aplicá-lo. Dia fará com que os pequenos passos extra dados no início se tornem saltos e limites de poupança mais tarde.

O MVVM adiciona o modelo de vista à mistura. Isso é importante, pois permite que você use uma grande parte da abordagem de vinculação do WPF, sem colocar todas essas peças específicas UI em seu modelo regular.

Posso estar errado, mas não sei se MVVM realmente força O controlador na mistura. Acho que o conceito está mais de acordo com: http://martinfowler.com/eaaDev/PresentationModel.html acho que as pessoas escolhem combiná - lo com o MVC, não que seja incorporado no padrao.

Do que posso dizer, o MVVM mapas para o MV de MVC, o que significa que em um tradicional padrão MVC o V não se comunica diretamente com o M., Na segunda versão do MVC, há uma ligação directa entre M e V. MVVM aparece para tirar todas as tarefas relacionadas com o M e V de comunicação, e um par para dissociar-o C. com efeito, ainda há o maior escopo de aplicativo de fluxo de trabalho (ou de implementação dos cenários de utilização) que não são totalmente considerados na MVVM. Este é o papel do controlador. Ao remover esses aspectos de nível inferior dos controladores, eles são mais limpos e torna mais fácil modificar o cenário de uso da aplicação e a lógica de negócios, também tornando os controladores mais reutilizáveis.

Injectar modelos de visualização fortemente tipados na janela usando o MVC

1. O controlador é responsável por preparar o modelo de visualização e injectá-lo na janela. (para obter pedidos)
2. o ViewModel é o container para o DataContext e o estado de visualização, como o último item seleccionado, etc.
3. o modelo contém entidades DB e está muito próximo do esquema DB que faz as consultas e filtragem. (Eu gosto de EF e LINQ para isso)
4. o modelo também deve considerar repositórios e ou projeção de resultados em tipos fortes (EF tem um grande método... EF.Banco.Seleccione (querystring, parms) para acesso directo ADO para injectar consultas e obter de volta tipos fortes. Isto aborda o argumento EF é lento. EF não é lento !
5. O modelo de visualização recebe os dados e faz as regras de negócio e validação
6. O controlador em post back irá ligar o método ViewModel Post e esperar pelos resultados.
7. O controlador irá injectar o novo o modelo de visualização actualizado para a janela. A vista usa apenas a ligação do tipo forte .
8. a vista apenas torna os dados, e envia eventos de volta para o controlador. (ver exemplos abaixo)
9. a MVC intercepta o pedido de entrada e encaminha - o para um controlador adequado com tipo de dados forte

Neste modelo não há mais nenhum nível HTTP contacto com os objectos de pedido ou resposta, dado que a máquina MVC do MSFT o esconde de nós.

Em clarificação do ponto 6 supra (mediante pedido)...

Assume um modelo como este:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

O método do controlador do post será semelhante a este (ver abaixo), note que a instância de mvm é automaticamente instanciada pelos mecanismos de ligação MVC. Você nunca tem que cair para a camada de texto da consulta como resultado! Este é o MVC a instanciar o modelo de visualização para si com base nos strings da consulta!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Note que para que esta acção funcione como pretende, você deve ter um CTOR nulo definido que intializa coisas não retornadas no post. O post back também deve postar os pares nome/valor para aquelas coisas que mudaram. Se houver pares de nome/valor faltando o motor de ligação MVC faz a coisa apropriada que é simplesmente nada! Se isso acontecer você pode encontrar-se dizendo "Eu estou perdendo dados em Post backs"...

A vantagem deste padrão é que o View Model faz todo o trabalho de" confusão " interfaceando com a lógica modelo/Buisness, o controlador é apenas uma espécie de router. É a SOC em acção.

Surpreende-me que esta seja uma resposta altamente votada sem mencionar a origem do MVVM. MVVM é um termo popular usado na Comunidade Microsoft e é originado a partir do modelo de apresentação de Martin Fowler . Assim, para entender o motivo do padrão e as diferenças com os outros, o artigo original sobre o padrão é a primeira coisa a ler.

[[1]} bem, geralmente MVC é usado no desenvolvimento da Web e MVVM é mais popular no desenvolvimento WPF / Silverlight. No entanto, às vezes o web architectute pode ter uma mistura de MVC e MVVM.

Por exemplo: pode usar knockout.js e neste caso terá MVVM do lado do seu cliente. E o lado do servidor do seu MVC também pode mudar. Nos aplicativos complexos, ninguém usa o modelo puro. Pode ter um sentido usar um modelo de vista como um" modelo " de MVC e seu modelo real, basicamente, será uma parte deste VM. Isto dá-lhe uma camada extra de abstracção.

[[1]}o MVVM, ou talvez o MVC+, parece ser uma abordagem viável para a empresa, bem como um rápido desenvolvimento de aplicações. Embora seja bom separar a IU da lógica de negócios e interação, o padrão MVVM "puro" e a maioria dos exemplos disponíveis funcionam melhor em visões singulares.

Não tenho certeza sobre seus projetos, mas a maioria das minhas aplicações, no entanto, contêm páginas e várias (reutilizáveis) vistas e, portanto, os modelos de visualização precisam interagir em algum grau. Usar a página como controlador derrotar o propósito do MVVM completamente, de modo que não usando uma abordagem "VM-C" para a lógica subjacente pode resultar em .. bem .. construções desafiadoras à medida que a aplicação amadurece. Mesmo no VB-6, a maioria de nós provavelmente parou de codificar a lógica de negócios no evento botão e começou a' relaying ' comandos para um controlador, certo? Eu recentemente olhei para muitas obras emergentes sobre esse tema; meu favorito claramente é a abordagem Magellan (no codeplex). Feliz código!

Http://en.wikipedia.org/wiki/Model_View_ViewModel#References

De um ponto de vista prático, MVC (Model-View-Controller) é um padrão. No entanto, a MVC quando utilizada como ASP.net MVC, quando combinado com o Entity Framework (EF) e as "power tools" é uma abordagem muito poderosa, parcialmente automatizada para trazer bases de dados, tabelas e colunas para uma página web, tanto para operações CRUD completas ou R (recuperar ou ler) apenas operações. Pelo menos como eu usei MVVM, os modelos de vista interagiram com modelos que dependiam de objetos de negócio, que eram por sua vez "feito à mão "e depois de muito esforço, teve a sorte de conseguir modelos tão bons quanto o que EF dá um"fora-da-caixa". De um ponto de vista de programação prática, MVC parece uma boa escolha, porque dá um monte de utilidade fora-da-caixa, mas ainda há um potencial para sinos-e-assobios a ser adicionado.

Complementar a muitas das respostas dadas, eu queria adicionar alguma perspectiva adicional do ponto de vista do cliente moderno ou aplicação web Rica.

Na verdade, hoje em dia, sites simples e aplicações web maiores são normalmente construídos com muitas bibliotecas populares, como o Bootstrap. Construído por Steve Sanderson, Knockout fornece suporte para o padrão MVVM que imita um dos comportamentos mais importantes no padrão: ligação de dados através do modelo View. Com um pequeno JavaScript, dados e lógica podem ser implementados que podem então ser adicionados a elementos de página com atributos HTML simples data-bind, semelhantes ao uso de muitas das características de Bootstrap . Juntos, Estas duas bibliotecas oferecem conteúdo interativo; e quando combinadas com o roteamento esta abordagem pode resultar em uma abordagem simples, mas poderosa, para construir a aplicação de uma única página .

Da mesma forma, um quadro moderno do lado do cliente, como Angular segue o padrão MVC por convenção, mas também adiciona um serviço. Curiosamente, ele é apontado como modelo-Vista-o que quer que (MVW). (Ver esta publicação no Stack Overflow .) Além disso, com a ascensão de quadros Web progressivos como o Angular 2, estamos vendo uma mudança de terminologia e talvez um novo padrão arquitetônico, onde componentes compreendem uma visão ou modelo e interagem com um serviço-tudo o que pode ser contido em um módulo; e uma série a aplicação é composta por módulos.

Costumava pensar que o MVC e o MVVM são iguais. Agora, por causa da existência do fluxo, eu posso dizer a diferença:

Em MVC, para cada vista no seu aplicativo, você tem um modelo e um controlador, então eu chamaria de vista, modelo de vista, controlador de vista. O padrão não lhe diz como uma visão pode se comunicar com outra. Portanto, em diferentes enquadramentos há diferentes implementações para isso. Por exemplo, existem implementações onde os controladores falam uns com os outros, enquanto que em outras implementações há outro componente que Media entre elas. Há até implementações em que os modelos de visão se comunicam entre si, o que é uma quebra do padrão MVC porque o modelo de vista só deve ser acessado pelo controlador de visualização.

Em MVVM, você também tem um modelo de vista para cada componente. O padrão não especifica como o heck a vista deve influenciar o modelo de vista, então geralmente a maioria dos frameworks apenas incluem a funcionalidade do controlador na vista modelo. No entanto, MVVM diz - lhe que os dados do seu modelo de vista devem vir do modelo, que é todo o modelo que não está ciente ou personalizado para uma visão específica.

Para demonstrar a diferença, tomemos o padrão do fluxo. O padrão de fluxo diz Como Diferentes vistas no aplicativo devem se comunicar. Cada Vista ouve uma loja e dispara ações usando o expedidor. O dispatcher, por sua vez, conta a todas as lojas sobre a ação que acabou de ser feita, e as lojas atualizam-se. Uma loja em Fluxo corresponde ao modelo (geral) em MVVM. não é personalizado para qualquer visão específica. Então, normalmente quando as pessoas usam Reat e Flux, cada componente Reat realmente implementa o padrão MVVM. Quando ocorre uma ação, o modelo view chama o dispatcher, e finalmente ele está sendo atualizado de acordo com as mudanças na loja, que é o modelo. Você não pode dizer que cada componente implementa MVC porque no MVC apenas o controlador pode atualizar o modelo de visualização. MVVM pode trabalhar com fluxo em conjunto (MVVM) lida com a comunicação entre a visão e o modelo de visão, e o fluxo lida com a comunicação entre diferentes visões), enquanto a MVC não pode trabalhar com fluxo sem quebrar um princípio chave.

As outras respostas podem não ser fáceis de entender para quem não está muito familiarizado com o tema dos padrões arquitetônicos. Alguém que é novo na arquitetura app pode querer saber como sua escolha pode afetar seu app na prática e o que todo o alarido é sobre as comunidades. A tentar esclarecer as coisas, inventei um guião que envolvia MVVM, MVP e MVC. A história começa por um utilizador carregar no botão 'Procurar' numa aplicação de pesquisa de filmes...:

Utilizador: Clique ...

Quem é aquele? [MVVM|MVP|MVC]

Acabei de carregar no botão de busca ...

ver : OK, espera um segundo ... . [MVVM|MVP|MVC]

( Visualizar chamando o ViewModel|Apresentador|Controlador de ... ) [MVVM|MVP|MVC]

ver : Hey Ver Modelo|apresentar|controlador , um utilizador acabou de carregar no botão Procurar, o que devo fazer? [MVVM|MVP|MVC]

ViewModel|apresentar|Controller : Hey View , existe algum termo de pesquisa nessa página? [MVVM|MVP|MVC]

ver : Sim, ... aqui está ... " piano "[MVVM|MVP|MVC]

-- Esta é a diferença mais importante entre MVVM E MVP|MVC ---

apresentador : obrigado ver , ... Enquanto isso eu estou olhando para cima o termo de busca no Modelo, por favor, mostre-lhe uma barra de progresso [MVP|MVC]

( Apresentador|Controlador é chamada a Modelo ... ) [MVP|MVC]

Vercontroller : Obrigado, vou procurar o termo de pesquisa no modelo mas não o actualizarei directamente. Em vez disso, vou desencadear eventos para procurar resultados lista observável se houver algum resultado. Então é melhor observares isso. [[[10]}MVVM]

(ao observar em qualquer gatilho no searchResultsListObservable, o View acha que deve mostrar alguma barra de progresso para o utilizador, uma vez que o ViewModel não falaria com ele sobre isso)

------------------------------

ViewModel|apresentar|controlador : Hey Modelo , tem alguma correspondência para este Termo de pesquisa?: "piano" [MVVM|MVP|MVC]

Modelo ViewModel|Apresentador|Controlador, deixe-me ver ... [MVVM|MVP|MVC]

( O Modelo está a fazer uma pesquisa na base de dados do filme...) [MVVM|MVP|MVC]

( Depois de um tempo...)

---- Este é o ponto divergente entre MVVM, MVP e MVC -----

Modelo : encontrei uma lista para ti, ViewModel|apresentador , Aqui está. is in JSON "[{"name": "Piano Teacher", "year": 2001}, {"name": "Piano", "year"":1993}]" [ MVVM|MVP]

Modelo : há algum resultado Disponível, controlador. Criei uma variável de campo no meu caso e preenchi-a com o resultado. Seu nome é " searchResultsList "[[[10]}MVC]

(Apresentador|Controlador graças Modelo e recebe de volta para a Visualizar) [MVP|MVC]

apresentador : Obrigado por esperar ver , encontrei uma lista de resultados correspondentes para si e organizei-os num formato apresentável: ["Piano Teacher 2001","Piano 1993"]. Também, por favor, esconda a barra de progresso agora [[[[10]}MVP]

controlador : Obrigado por esperar ver, perguntei ao modelo sobre a sua pesquisa. Ele diz que encontrou uma lista de resultados correspondentes e armazenou - os em uma variável chamada "searchResultsList" dentro de sua instância. Podes ir buscá-lo a partir daí. Por favor, também esconda o barra de progresso agora [MVC]

ViewModel : qualquer observador em pesquisas listadas deve ser notificado de que existe esta nova lista em formato apresentável: ["Piano Teacher 2001","Piano 1993"].[[[10]}MVVM]

ver : Muito obrigado apresentador [MVP]

ver : obrigado " controlador" [MVC ] (Agora a visão está a questionar-se: como devo apresentar os resultados que recebo do Modelopara o utilizador? O ano de produção do filme deve vir em primeiro ou em último...?)

View {[[9]}: Oh, há um novo gatilho em searchResultsListObservable..., bom, há uma lista apresentável, agora só tenho que mostrá-la em uma lista. Eu também deveria esconder a barra de progresso agora que tenho o resultado. [[[10]}MVVM]

Caso esteja interessado, escrevi uma série de artigos aqui , comparando MVVM, MVP e MVC, implementando um aplicativo android de pesquisa de filmes.

O controlador não é substituído por um modelo de visualização em MVVM, porque o modelo de visualização tem uma funcionalidade totalmente diferente do que um controlador. Você ainda precisa de um Controller, porque sem um Controller seu modelo, ViewModel e View não vai fazer muito... Em MVVM você tem um controlador também, o nome MVVM é apenas Miss leading.

MVVVMC é o nome correcto na minha humilde opinião.

Como pode ver, o modelo de visualização é apenas uma adição ao padrão de MVC. Ele move conversion-logic (para exemplo converter objeto para uma cadeia de caracteres) do controlador para o modelo de visualização.

O Mvc é do lado do servidor e o mvvm é do lado do cliente(navegador) no desenvolvimento da web.

A maior parte do tempo javascript é usado para mvvm no navegador. existem muitas tecnologias server side para mvc.