Qual é a diferença entre MVC e MVVM?

Existe uma diferença entre o padrão padrão “Model View Controller” e o padrão Model / View / ViewModel da Microsoft?

O MVC / MVVM não é uma opção de escolha.

Os dois padrões surgem de diferentes maneiras, tanto no desenvolvimento do ASP.Net quanto do Silverlight / WPF.

Para ASP.Net, o MVVM é usado para associar dados bidirecionais a visualizações. Isso geralmente é uma implementação do lado do cliente (por exemplo, usando o Knockout.js). O MVC, por outro lado, é uma maneira de separar as preocupações no lado do servidor .

Para o Silverlight e o WPF, o padrão MVVM é mais abrangente e pode parecer agir como um substituto do MVC (ou outros padrões de organização de software em responsabilidades separadas). Uma suposição, que freqüentemente saiu desse padrão, foi que o ViewModel simplesmente substituiu o controlador no MVC (como se você pudesse simplesmente replace o VM por C no acrônimo e tudo seria perdoado) …

O ViewModel não substitui necessariamente a necessidade de controladores separados.

O problema é que, para ser testável independentemente * e, especialmente, reutilizável quando necessário, um modelo de visão não tem ideia de qual exibição está exibindo, mas, mais importante, não tem idéia de onde seus dados estão vindo .

* Nota: na prática, os Controladores removem a maior parte da lógica, do ViewModel, que requer teste de unidade. A VM, em seguida, torna-se um contêiner burro que requer pouco ou nenhum teste. Isso é uma coisa boa, já que a VM é apenas uma ponte, entre o designer e o codificador, então deve ser mantida simples.

Mesmo no MVVM, os controladores normalmente contêm toda a lógica de processamento e decidem quais dados exibir em quais exibições usar quais modelos de visualização.

Pelo que vimos até agora, o principal benefício do padrão ViewModel é remover o código do XAML code-behind para tornar a edição XAML uma tarefa mais independente . Nós ainda criamos controladores, como e quando necessário, para controlar (sem trocadilhos) a lógica geral de nossas aplicações.

As diretrizes básicas do MVCVM que seguimos são:

  • As exibições exibem uma determinada forma de dados . Eles não têm ideia de onde vêm os dados.
  • Os ViewModels possuem uma certa forma de dados e comandos , eles não sabem de onde os dados, ou códigos, vêm ou como são exibidos.
  • Os modelos armazenam os dados reais (vários contextos, armazenamento ou outros methods)
  • Controladores ouvem e publicam events. Controladores fornecem a lógica que controla quais dados são vistos e onde. Controladores fornecem o código de comando para o ViewModel para que o ViewModel seja realmente reutilizável.

Também notamos que a estrutura code-gen Sculpture implementa o MVVM e um padrão semelhante ao Prism E também faz uso extensivo de controladores para separar toda a lógica de casos de uso.

Não assuma que os controladores sejam tornados obsoletos pelos modelos View.

Eu comecei um blog sobre este tópico que eu adicionarei como e quando eu puder . Há problemas com a combinação do MVCVM com os sistemas de navegação comuns, já que a maioria dos sistemas de navegação usa apenas Views e VMs, mas abordarei isso em artigos posteriores.

Um benefício adicional do uso de um modelo MVCVM é que apenas os objects do controlador precisam existir na memory durante a vida útil do aplicativo e os controladores contêm principalmente código e poucos dados de estado (ou seja, pequena sobrecarga de memory). Isso gera menos aplicativos que consomem muita memory do que soluções em que os modelos de visualização precisam ser mantidos e é ideal para certos tipos de desenvolvimento móvel (por exemplo, o Windows Mobile usando o Silverlight / Prism / MEF). Isso depende, é claro, do tipo de aplicativo, pois talvez você ainda precise manter as VMs em cache ocasionais para a capacidade de resposta.

Observação: essa postagem foi editada várias vezes e não foi especificamente direcionada à questão restrita, então atualizei a primeira parte para agora abordar isso também. Grande parte da discussão, nos comentários abaixo, refere-se apenas ao ASP.Net e não ao quadro mais amplo. Este post foi concebido para cobrir o uso mais amplo do MVVM no Silverlight, WPF e ASP.Net e tentar evitar que as pessoas substituam os controladores por ViewModels.

Acho que a maneira mais fácil de entender o que essas siglas significam é esquecê-las por um momento. Em vez disso, pense no software com o qual se originou, cada um deles. Isso realmente se resume a apenas a diferença entre o início da web e o desktop.

O primeiro acrônimo, MVC, originou-se na web. (Sim, pode ter sido lá antes, mas a web é como ela se popularizou para as massas de desenvolvedores da web.) Pense database, páginas HTML e código entre eles. Vamos refinar isso apenas um pouquinho para chegar ao MVC: Para »database«, vamos assumir o database mais o código da interface. Para “páginas HTML”, suponhamos modelos HTML e código de processamento de modelo. Para “código intermediário”, suponhamos que o mapeamento de código clica nos usuários para ações, possivelmente afetando o database, definitivamente fazendo com que outra visualização seja exibida. É isso, pelo menos para o propósito desta comparação.

Vamos manter uma característica deste material da Web, não como é hoje, mas como existia há dez anos, quando o Javascript era um aborrecimento humilde e desprezível, que os programadores reais faziam bem em evitar: A página HTML é essencialmente idiota e passiva . O navegador é um thin client ou, se preferir, um cliente fraco. Não há inteligência no navegador. A página completa recarrega a regra. A »visão« é gerada novamente a cada vez.

Vamos lembrar que esta forma de web, apesar de ser toda a raiva, foi terrivelmente atrasada em comparação com a área de trabalho. Aplicativos de desktop são clientes gordos ou clientes ricos, se você quiser. (Até mesmo um programa como o Microsoft Word pode ser considerado como um tipo de cliente, um cliente para documentos.) Eles são clientes cheios de inteligência, cheios de conhecimento sobre seus dados. Eles são stateful. Eles armazenam em cache os dados que estão manipulando na memory. Nenhuma porcaria como uma recarga de página inteira.

E essa rica maneira de desktop é provavelmente onde o segundo acrônimo se originou, o MVVM. Não se deixe enganar pelas letras, pela omissão do C. Controladores ainda estão lá. Eles precisam ser. Nada é removido. Adicionamos apenas uma coisa: estado, dados em cache no cliente (e junto com ele a inteligência para lidar com esses dados). Esses dados, essencialmente um cache no cliente, agora são chamados de “ViewModel”. É o que permite interatividade rica. E é isso.

  • MVC = modelo, controlador, visualização = essencialmente comunicação unidirecional = interatividade deficiente
  • MVVM = modelo, controlador, cache, view = comunicação bidirecional = interatividade rica

Podemos ver que, com o Flash, o Silverlight e, mais importante, o Javascript, a Web adotou o MVVM. Os navegadores não podem mais ser legitimamente chamados de thin clients. Veja a programação deles. Veja o consumo de memory deles. Veja toda a interatividade do Javascript em páginas da web modernas.

Pessoalmente, acho que esse negócio de teoria e acrônimo é mais fácil de entender, olhando para o que se refere à realidade concreta. Conceitos abstratos são úteis, especialmente quando demonstrados em matéria concreta, de modo que o entendimento pode vir em um círculo completo.

MVVM Model-View ViewModel é semelhante ao MVC, Model-View Controller

O controlador é substituído por um ViewModel . O ViewModel fica abaixo da camada da interface do usuário. O ViewModel expõe os dados e os objects de comando de que a visualização precisa. Você poderia pensar nisso como um object de contêiner que a visualização utiliza para obter seus dados e ações. O ViewModel puxa seus dados do modelo.

Russel East faz um blog discutindo mais detalhadamente Por que o MVVM é diferente do MVC?

Por um lado, o MVVM é uma progressão do padrão MVC que usa o XAML para manipular a exibição. Este artigo descreve algumas das facetas dos dois.

O principal impulso da arquitetura Model / View / ViewModel parece ser que no topo dos dados (“o modelo”), há outra camada de componentes não-visuais (“o ViewModel”) que mapeiam os conceitos dos dados mais de perto aos conceitos da visão dos dados (”a vista”). É o ViewModel ao qual o View se vincula, não o Model diretamente.

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

No padrão de design Model-View-ViewModel, um aplicativo é composto de três componentes gerais. insira a descrição da imagem aqui

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

  • Visualização : um aplicativo geralmente é composto de várias páginas da interface do usuário. Cada página mostrada ao usuário é uma visualização na terminologia do MVVM. A visualização é o código XAML usado para definir e estilizar 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 interface com os dados com base no estado atual do aplicativo. Por exemplo, em um aplicativo de compartilhamento de imagens, as visualizações seriam a interface do usuário que mostra ao usuário a lista de álbuns no dispositivo, as imagens em um álbum e talvez outro que mostre ao usuário uma imagem específica.

  • ViewModel : O ViewModel vincula o modelo de dados, ou simplesmente o modelo, à interface do usuário ou exibições do aplicativo. 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 do usuário ou modos de exibição XAML podem se vincular. Por exemplo, em um aplicativo de compartilhamento de imagens, o ViewModel exporia uma lista de álbuns e, para cada álbum, exibiria uma lista de fotos. A interface do usuário é agnóstica de onde as imagens vêm e como são recuperadas. Ele simplesmente conhece um conjunto de imagens conforme exposto pelo ViewModel e as mostra ao usuário.

Eu pensei que uma das principais diferenças era que no MVC, seu V lê seu M diretamente, e passa pelo C para manipular os dados, enquanto que no MVVM, sua VM atua como um proxy M, bem como fornecendo 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 sua VM é apenas um proxy M e C fornece todas as funcionalidades.

Diferença Simples: (Inspirado no curso Coursera AngularJS de Yaakov)

insira a descrição da imagem aqui

MVC (Model View Controller)

  1. Modelos: os modelos contêm informações de dados. Não chama ou usa o Controlador e a Visualização. Contém a lógica de negócios e formas de representar dados. Alguns desses dados, de alguma forma, podem ser exibidos na exibição. Também pode conter lógica para recuperar os dados de alguma fonte.
  2. Controlador: Atua como a conexão entre a visão e o modelo. Exibir chamadas O Controlador e o Controlador chamam o modelo. Basicamente, ele informa o modelo e / ou a visão para alterar conforme apropriado.
  3. Ver: lida com parte da interface do usuário. Interage com o usuário.

MVVM (Model View View Model)

ViewModel :

  1. É a representação do estado da visão.
  2. Ele contém os dados exibidos na exibição.
  3. Responde para ver events, também conhecidos como lógica de apresentação.
  4. Chama outras funcionalidades para processamento de lógica de negócios.
  5. Nunca pede diretamente a exibição para exibir nada.

MVVM é um refinamento (discutível) do padrão Modelo de Apresentação . Digo discutível, porque a única diferença está em como o WPF fornece a capacidade de fazer vinculação de dados e manipulação de comandos.

O viewmodel é um modelo “abstrato” para os elementos da interface do usuário. Ele deve permitir que você execute os comandos e ações em sua visão de maneira não visual (por exemplo, para testá-lo).

Se você trabalhou com o MVC, você provavelmente achou útil criar objects de modelo para refletir o estado de sua visualização, por exemplo, para mostrar e ocultar alguma checkbox de diálogo de edição, etc. Nesse caso, você está usando um viewmodel.

O padrão MVVM é simplesmente a generalização dessa prática para todos os elementos da interface do usuário.

E não é um padrão da Microsoft, o que acrescenta é que as ligações de dados do WPF / Silverlight são especialmente adequadas para trabalhar com esse padrão. Mas nada impede que você o use com faces do servidor java, por exemplo.

O MVC é um ambiente controlado e o 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. Contudo; no mundo da web, o MVC é facilmente dividido em lógica de criação de visualizações e exibe a lógica dinâmica. A criação vive no servidor e a vida dinâmica no cliente. Você vê muito isso com o ASP.NET MVC combinado com o AngularJS, enquanto o servidor criará um View e passará um Modelo e o enviará ao cliente. O cliente irá então interagir com o View, em cujo caso o 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á muitas outras traduções dessa manipulação quando se trabalha com sockets ou AJAX etc, mas sobre toda a arquitetura é idêntica).

O MVVM é um ambiente reativo, o que significa que você normalmente escreve código (como gatilhos) que será ativado com base em algum evento. Em XAML, onde o MVVM prospera, tudo isso é feito facilmente com a estrutura de binding de dados construída, MAS, como mencionado, isso funcionará em qualquer sistema em qualquer View com qualquer linguagem de programação. Não é específico da MS. O ViewModel é acionado (geralmente, um evento de propriedade alterada) e a View reage a ele com base nos acionadores que você cria. Isso pode ser técnico, mas a linha de fundo é que o View é sem estado e sem lógica. Simplesmente muda de estado baseado em valores. Além disso, os ViewModels são sem estado com muito pouca lógica, e os modelos são o estado com lógica essencialmente zero, pois devem manter apenas o estado. Eu descrevo isso como estado da aplicação (Model), tradutor de estado (ViewModel) e, em seguida, o estado visual / interação (View).

Em uma área de trabalho do MVC ou no aplicativo do lado do cliente, você deve ter um Modelo, e o Modelo deve ser usado pelo Controlador. Com base no modelo, o controlador modificará a visualização. As visualizações geralmente são vinculadas a Controladores com Interfaces para que o Controlador possa trabalhar com uma variedade de Visualizações. No ASP.NET, a lógica do MVC é um pouco para trás no servidor, pois o Controlador gerencia os Modelos e passa os Modelos para uma Visualização selecionada. A View é então preenchida com dados baseados no modelo e possui sua própria lógica (geralmente outro conjunto MVC, como feito com o AngularJS). As pessoas vão discutir e confundir isso com o aplicativo MVC e tentar fazer as duas coisas, e nesse ponto, manter o projeto acabará se tornando um desastre. SEMPRE coloque a lógica e o controle em um local ao usar o MVC. NÃO escreva Exibir lógica no código por trás da Visualização (ou na Visualização 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 visão é 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. Seja na área de trabalho ou na página da Web (no cliente), o Controlador deve manipular o processo de envio sempre que a Ação de Exibição for acionada. Se feito corretamente, você pode sempre encontrar seu caminho em torno de um aplicativo web ou aplicativo local MVC facilmente.

O MVVM é pessoalmente meu favorito, pois é completamente reativo. Se um modelo muda de estado, o ViewModel ouve e traduz esse estado e é isso !!! O View, em seguida, está ouvindo o ViewModel para alteração de estado e também atualiza com base na tradução do ViewModel. Algumas pessoas chamam isso de MVVM puro, mas há realmente apenas um e não me importa como você argumenta e é sempre MVVM puro, onde o View não contém absolutamente nenhuma lógica.

Aqui está um pequeno exemplo: digamos que você quer ter um slide de menu em um botão pressionado. No MVC, você terá uma ação MenuPressed na sua interface. O Controlador saberá quando você clicar no botão Menu e, em seguida, informará ao Modo de Exibição para deslizar no Menu com base em outro método de Interface, como o SlideMenuIn. Uma viagem de ida e volta por qual razão? Incase o controlador decide que você não pode ou quer fazer outra coisa em vez disso é por isso. O Controlador deve estar encarregado da Visualização com a Visão, sem fazer nada, a menos que o Controlador diga isso. CONTUDO; No MVVM, o menu de slides na animação deve ser construído e genérico e, em vez de ser solicitado a inseri-lo, ele será baseado em algum valor. Então ele escuta o ViewModel e quando o ViewModel diz, IsMenuActive = true (ou no entanto) a animação para isso acontece. Agora, com isso dito, quero fazer outro ponto REALMENTE CLARO e POR FAVOR, prestar atenção. IsMenuActive é provavelmente design BAD MVVM ou ViewModel. Ao projetar um ViewModel, você nunca deve presumir que um View terá quaisquer resources e apenas transmitirá o estado do modelo traduzido. Dessa forma, se você decidir alterar sua Visualização para remover o Menu e apenas mostrar os dados / opções de outra maneira, o ViewModel não se importa. Então, como você administraria o Menu? Quando os dados fazem sentido, é assim. Portanto, uma maneira de fazer isso é dar ao Menu uma lista de opções (provavelmente uma matriz de ViewModels internos). Se essa lista tiver dados, o Menu saberá abrir através do gatilho, senão sabe esconder através do gatilho. Você simplesmente tem dados para o menu ou não no ViewModel. NÃO decida mostrar / ocultar esses dados no ViewModel. Simplesmente traduza o estado do Modelo. Desta forma, o View é completamente reativo e genérico e pode ser usado em muitas situações diferentes.

Tudo isso provavelmente não fará absolutamente nenhum sentido se você ainda não estiver familiarizado com a arquitetura de cada um deles e aprender isso pode ser muito confuso, já que você encontrará ALOT OF BAD na internet.

Então … coisas para manter em mente para acertar isso. Decida de antemão como projetar seu aplicativo e STICK TO IT.

Se você faz MVC, o que é ótimo, então certifique-se de que o Controller seja gerenciável e tenha controle total da sua View. Se você tiver uma visualização grande, considere adicionar controles à Visualização que tenham Controladores diferentes. APENAS NÃO conecte esses controladores a controladores diferentes. Muito frustrante para manter. Separe um momento e projete as coisas separadamente de uma maneira que funcione como componentes separados … E sempre deixe o Controlador dizer ao Model para confirmar ou persistir o armazenamento. A configuração de dependência ideal para MVC é View ← Controller → Model ou com ASP.NET (não me faça começar) Model ← View ↔ Controller → Model (onde Model pode ser o mesmo ou um modelo totalmente diferente de Controller para View) … claro que a única necessidade de saber de Controller in View neste ponto é principalmente para referência de terminal para saber onde voltar a passar um Model.

Se você faz MVVM, eu abençoo sua alma gentil, mas aproveite o tempo para fazer isso certo! Não use interfaces para um. Deixe sua visualização decidir como ela será baseada nos valores. Jogue com os dados View with Mock. Se você acabar tendo um View que está mostrando um Menu (como no exemplo), mesmo que você não o queira no momento, então BOA. Sua visão está funcionando como deveria e reagindo com base nos valores como deveria. Basta adicionar mais alguns requisitos ao seu gatilho para garantir que isso não aconteça quando o ViewModel estiver em um determinado estado traduzido ou comande o ViewModel para esvaziar esse estado. Em seu ViewModel, NÃO remova isso com a lógica interna, como se você estivesse decidindo se a visualização deveria ou não ser vista. Lembre-se que você não pode presumir que há um menu ou não no ViewModel. E, finalmente, o modelo deve apenas permitir que você mude e, provavelmente, armazene o estado. É aí que a validação e tudo ocorrerá; por exemplo, se o Modelo não puder modificar o estado, ele simplesmente se sinalizará como sujo ou algo assim. Quando o ViewModel percebe isso, ele traduz o que está sujo, e o View percebe isso e mostra algumas informações através de outro trigger. Todos os dados na View podem ser vinculados ao ViewModel, então tudo pode ser dynamic, apenas o Model e o ViewModel não têm absolutamente nenhuma idéia sobre como a View reagirá à binding. De fato, o Modelo não tem idéia de um ViewModel. Ao configurar as dependencies, elas devem apontar como e somente assim View → ViewModel → Model (e uma nota lateral aqui … e isso provavelmente será discutido também, mas eu não me importo … NÃO PASSE O MODELO para A vista não deve ver um período de modelo.Eu dou um rato rachar o demo que você viu ou como você fez isso, isso é errado.)

Aqui está minha dica final … Olhe para um aplicativo MVC bem projetado, mas muito simples, e faça o mesmo com um aplicativo 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 gerenciar todo o aplicativo a partir de um conjunto de controladores ou (uma única fonte), enquanto um ambiente reativo pode ser dividido em repositorys separados sem a mínima ideia do que o restante do aplicativo está fazendo. Gestão Micro vs gestão gratuita.

Se eu não o confundi o suficiente, tente entrar em contato comigo … Eu não me importo de examinar isso detalhadamente com ilustrações e exemplos.

No final do dia, somos todos programadores e com isso a anarquia vive dentro de nós quando codificamos … Então as regras serão quebradas, as teorias mudarão, e tudo isso terminará em sujeira … Mas quando se trabalha em grandes projetos e em grandes equipes, realmente ajuda a concordar com um padrão de projeto e aplicá-lo. Um dia, os pequenos passos adicionais tomados no início tornam-se trancos e barrancos de poupança mais tarde.

O MVVM adiciona o modelo de visualização ao mix. Isso é importante, pois permite que você use muito a abordagem de vinculação do WPF, sem colocar todas as partes específicas da interface do usuário em seu modelo regular.

Eu posso estar errado, mas não tenho certeza se o MVVM realmente força o controlador na mixagem. Eu acho que o conceito está mais de acordo com: http://martinfowler.com/eaaDev/PresentationModel.html . Eu acho que as pessoas escolhem combiná-lo com o MVC, não que ele esteja embutido no padrão.

Pelo que eu posso dizer, o MVVM mapeia para o MV do MVC – o que significa que em um padrão MVC tradicional o V não se comunica diretamente com o M. Na segunda versão do MVC, há um link direto entre M e V. MVVM appears to take all tasks related to M and V communication, and couple it to decouple it from the C. In effect, there’s still the larger scope application workflow (or implementation of the use scenarios) that are not fully accounted for in MVVM. This is the role of the controller. By removing these lower level aspects from the controllers, they are cleaner and makes it easier to modify the application’s use scenario and business logic, also making controllers more reusable.

Injecting Strongly Typed ViewModels into the View using MVC

  1. The controller is responsible for newing up the ViewModel and injecting it into the View. (for get requests)
  2. The ViewModel is the container for DataContext and view state such as the last selected item etc.
  3. The Model contains DB entities and is very close to the DB Schema it does the queries and filtering. (I like EF and LINQ for this)
  4. The Model should also consider repositories and or projection of results into strong types (EF has a great method… EF.Database.Select(querystring, parms) for direct ADO access to inject queries and get back strong types. This addresses the EF is slow argument. EF is NOT SLOW !
  5. The ViewModel gets the data and does the business rules and validation
  6. The controller on post back will cal the ViewModel Post method and wait for results.
  7. The controller will inject the newly updated Viewmodel to the View. The View uses only strong type binding .
  8. The view merely renders the data, and posts events back to the controller. (see examples below)
  9. MVC intercepts the inbound request and routes it to proper controller with strong data type

In this model there is no more HTTP level contact with the request or response objects as MSFT’s MVC machine hides it from us.

In clarification of item 6 above (by request)…

Assume a ViewModel like this:

 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!"; } } 

The controller method of the post will look like this (See below), note that the instance of mvm is automatically instanciated by the MVC binding mechanisms. You never have to drop down to the query string layer as a result! This is MVC instantiating the ViewModel for you based on the query strings!

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

Note that in order for this actionmethod above to work as you intend, you must have a null CTOR defined that intializes things not returned in the post. The post back must also post back name/value pairs for those things which changed. If there are missing name/value pairs the MVC binding engine does the proper thing which is simply nothing! If this happens you might find yourself saying “I’m losing data on post backs”…

The advantage of this pattern is the ViewModel does all the “clutter” work interfacing to the Model/Buisness logic, the controller is merely a router of sorts. It is SOC in action.

It surprises me that this is a highly voted answers without mentioning the origin of MVVM. MVVM is a popular term used in Microsoft community and it is originated from Martin Fowler’s Presentation Model . So to understand the motive of the pattern and the differences with others, the original article about the pattern is the first thing to read.

Well, generally MVC is used in Web development and MVVM is most popular in WPF/Silverlight development. However, sometimes the web architecute might have a mix of MVC and MVVM.

For example: you might use knockout.js and in this case you will have MVVM on your client side. And your MVC’s server side can also change. In the complex apps, nobody uses the pure Model. It might have a sense to use a ViewModel as a “Model” of MVC and your real Model basically will be a part of this VM. This gives you an extra abstraction layer.

MVVMC, or perhaps MVC+, seems to be a viable approach for enterprise as well as rapid application development. While it is nice to separate the UI from business and interaction logic, the ‘pure’ MVVM pattern and most available examples work best on singular views.

Not sure about your designs, but most of my applications, however, contain pages and several (reusable) views and thus the ViewModels do need to interact to some degree. Using the page as controller would defeat the purpose of the MVVM altogether, so not using a “VM-C” approach for the underlying logic might result in .. well .. challenging constructs as the application matures. Even in VB-6 most of us probably stopped coding business logic into the Button event and started ‘relaying’ commands to a controller, right? I recently looked at many emerging framworks on that topic; my favorite clearly is the Magellan (at codeplex) approach. Codificação feliz!

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

From a practical point of view, MVC (Model-View-Controller) is a pattern. However, MVC when used as ASP.net MVC, when combined with Entity Framework (EF) and the “power tools” is a very powerful, partially automated approach for bringing databases, tables, and columns to a web-page, for either full CRUD operations or R (Retrieve or Read) operations only. At least as I used MVVM, the View Models interacted with models that depended upon business objects, which were in turn “hand-made” and after a lot of effort, one was lucky to get models as good as what EF gives one “out-of-the-box”. From a practical programming point of view, MVC seems a good choice because it gives one lots of utility out-of-box, but there is still a potential for bells-and-whistles to be added.

Complementary to many of the responses given, I wanted to add some additional perspective from the Modern client-side web – or Rich Web Application point of view.

Indeed these days simple web sites and larger web applications are commonly built with many popular libraries such as Bootstrap. Built by Steve Sanderson, Knockout provides support for the MVVM pattern which mimics one of the most important behaviors in the pattern: data-binding through the View Model. With a little JavaScript, data and logic can be implemented that can then be added to page elements with simple data-bind HTML attributes, similar to using many of the features of Bootstrap . Together, these two libraries alone offer interactive content; and when combined with routing this approach can result in a simple-yet-powerful approach to building the Single Page Application .

Similarly, a Modern client-side framework such as Angular follows the MVC pattern by convention, but also adds a Service. Interestingly, it is touted as Model-View-Whatever (MVW). (See this post on Stack Overflow .)

Additionally, with the rise of Progressive web frameworks such as Angular 2, we’re seeing a change in terminology and perhaps a new architectural pattern where Components comprise of a View or Template and interact with a Service – all of which can be contained in a Module; and a series of Modules makes up the application.

I used to think that MVC and MVVM are the same. Now because of the existence of Flux I can tell the difference:

In MVC, for each view in your app, you have a model and a controller, so I would call it view, view model, view controller. The pattern does not tell you how one view can communicate with another. Therefore, in different frameworks there are different implementations for that. For example there are implementations where controllers talk to each other whereas in other implementations there’s another component that mediates between them. There are even implementations in which the view models communicate with each other, which is a break of the MVC pattern because the view model should only be accessed by the view controller.

In MVVM, you also have a view model for each component. The pattern does not specify how the heck the view should influence the view model, so usually most frameworks just include controller’s functionality in the view model. However, MVVM does tell you that your view model’s data should come from the model, which is the entire model that’s not aware or custom to a specific view.

To demonstrate the difference, let’s take Flux pattern. Flux pattern tells how different views in the app should communicate. Each view listens to a store and fires actions using the dispatcher. The dispatcher in turn tells all the stores about the action that was just made, and the stores update themselves. A store in Flux corresponds to the (general) model in MVVM. it’s not custom to any specific view. So usually when people use React and Flux, each React component actually implements the MVVM pattern. When an action occurs, the view model calls the dispatcher, and finally it’s getting updated according to the changes in the store, which is the model. You can’t say that each component implements MVC because in MVC only the controller can update the view model. So MVVM can work with Flux together (MVVM handles the communication between the view and the view model, and Flux handles the communication between different views), whereas MVC can’t work with Flux without breaking a key principle.

mvc is server-side and mvvm is client-side(browser) in web development.

most of the time javascript is used for mvvm in browser. there are many server side technologies for mvc.

The other answers might not be easy to understand for one who is not much familiar with the subject of architectural patterns. Someone who is new to app architecture might want to know how its choice can affect her app in practice and what all the fuss is about in communities.

Trying to shed some light on the above, I made up this screenplay involving MVVM, MVP and MVC. The story begins by a user clicking on the ‘FIND’ button in a movie search app… :

User: Click …

View : Quem é esse? [ MVVM|MVP|MVC ]

Usuário: Eu apenas cliquei no botão de pesquisa…

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

( View calling the ViewModel | Presenter | Controller … ) [ MVVM|MVP|MVC ]

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

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

View : Yes,… here it is … “piano” [ MVVM|MVP|MVC ]

—— This is the most important difference between MVVM AND MVP | MVC ———

Apresentador : Obrigado Ver ,… enquanto estou pesquisando o termo de pesquisa no Modelo , mostre a ele uma barra de progresso [ MVP | MVC ]

( Presenter | Controller está chamando o Model …) [ MVP | MVC ]

ViewController : Thanks, I’ll be looking up the search term on the Model but will not update you directly. Instead, I will trigger events to searchResultsListObservable if there is any result. So you had better observe on that. [ MVVM ]

(While observing on any trigger in searchResultsListObservable, the View thinks it should show some progress bar to the user, since ViewModel would not talk to it on that)

——————————————————————————————

ViewModel | Apresentador | Controller : Hey Model , Do you have any match for this search term?: “piano” [ MVVM | MVP | MVC ]

Model : Hey ViewModel | Apresentador | Controller , let me check … [ MVVM | MVP | MVC ]

( Model is making a query to the movie database … ) [ MVVM | MVP | MVC ]

( After a while … )

———— This is the diverging point between MVVM , MVP and MVC ————–

Model : I found a list for you, ViewModel | Presenter , here it is in JSON “[{“name”:”Piano Teacher”,”year”:2001},{“name”:”Piano”,”year”:1993}]” [ MVVM | MVP ]

Model : There is some result available, Controller. Eu criei uma variável de campo na minha instância e preenchai com o resultado. It’s name is “searchResultsList” [ MVC ]

( Presenter | Controller agradece a Model e volta para a View ) [ MVP | MVC ]

Presenter : Thanks for waiting View , I found a list of matching results for you and arranged them in a presentable format: [“Piano Teacher 2001″,”Piano 1993”]. Também por favor esconda a barra de progresso agora [ MVP ]

Controller : Thanks for waiting View , I have asked Model about your search query. It says it has found a list of matching results and stored them in a variable named “searchResultsList” inside its instance. Você pode obtê-lo de lá. Também por favor esconda a barra de progresso agora [ MVC ]

ViewModel : Any observer on searchResultsListObservable be notified that there is this new list in presentable format: [“Piano Teacher 2001″,”Piano 1993”].[ MVVM ]

View : Thank you very much Presenter [ MVP ]

View : Thank you “ Controller ” [ MVC ] (Now the View is questioning itself: How should I present the results I get from the Model to the user? Should the production year of the movie come first or last…?)

View : Oh, there is a new trigger in searchResultsListObservable … , good, there is a presentable list, now I only have to show it in a list. I should also hide the progress bar now that I have the result. [ MVVM ]

In case you are interested, I have written a series of articles here , comparing MVVM, MVP and MVC by implementing a movie search android app.

The Controller is not replaced by a ViewModel in MVVM, because the ViewModel has a totally different functionality then a Controller. You still need a Controller, because without a Controller your Model, ViewModel and View will not do much… In MVVM you have a Controller too, the name MVVM is just missleading.

MVVMC is the correct name in my humble opinion.

As you can see the ViewModel is just an addition to the MVC pattern. It moves conversion-logic (for example convert object to a string) from the Controller to the ViewModel.