O Model cuida dos dados e das regras; a View é a interface; o ViewModel prepara informações e ações para a tela.
A ligação entre View e ViewModel é tradicionalmente feita por data binding, ou vinculação de dados: um mecanismo que mantém a interface sincronizada com o estado exposto pelo ViewModel.
Como separar negócio, interface e apresentação?
A distinção entre lógica de negócio, interface e apresentação define as responsabilidades de Model, View e ViewModel.
O ViewModel faz a ponte entre a tela e o Model, mas não assume o comportamento do negócio.
Uma forma prática de compreender a divisão é observar o tipo de decisão envolvido. Calcular um total pertence ao negócio. Exibir um campo pertence à interface. Preparar o resultado para exibição e controlar o estado da tela pertencem à apresentação.
Model: dados e regras de negócio
O Model reúne o que a aplicação sabe e as regras que aplica a esses dados. Sua composição varia: entidades, acesso a dados, serviços e validações são exemplos, não uma estrutura obrigatória de arquivos.
A ausência de dependência da interface favorece a reutilização. Uma regra de cálculo permanece separada dos botões e campos usados para apresentar seu resultado. Isso permite reutilizar a lógica em diferentes telas, respeitadas as demais dependências da implementação.
View: elementos visuais e interação
A View é a parte com a qual o usuário interage. Ela apresenta informações e recebe cliques, toques e digitação. Sua responsabilidade é a interface, não a decisão sobre regras de negócio.
No exemplo de um pedido, a View exibe o campo de cupom, o botão para aplicá-lo e o total. A regra que determina o desconto pertence ao Model.
ViewModel: estado e ações da tela
O ViewModel concentra a lógica de apresentação. Ele prepara os dados recebidos do Model, mantém o estado necessário à exibição e expõe as ações que a View aciona.
Estado é o conjunto de informações que descreve a situação da tela. Comandos são ações expostas pelo ViewModel, como solicitar a aplicação de um cupom. Essa coordenação não transfere a regra do desconto para a lógica de apresentação.
A tabela reúne esses limites: o Model mantém dados e regras sem depender da tecnologia da interface; o ViewModel expõe estado e ações sem conhecer a tela. Essa separação de responsabilidades e sua relação com testes e manutenção permite avaliar a lógica de apresentação sem instanciar uma interface visual.
Componente
Responsabilidade
Exemplos de conteúdo
Limite
Model
Manter os dados e executar a lógica de negócio
Entidades, acesso a dados, serviços de negócio e validação
Não depende da tecnologia usada na interface
View
Exibir a interface e receber a interação do usuário
Telas, botões, campos e listas
Não contém regras de negócio
ViewModel
Preparar dados para exibição, manter o estado da tela e expor ações
Propriedades, comandos e métodos de apoio à apresentação
Não referencia diretamente a View nem concentra o comportamento do negócio
Por que separar o ViewModel da View ajuda nos testes?
O ViewModel expõe estado e ações sem manter uma referência direta à View. A interface se conecta a esses elementos por binding ou por uma ligação manual, sem exigir que o ViewModel conheça a tela que o utiliza.
Com essa separação, os testes unitários, que verificam uma unidade de código isoladamente, avaliam a lógica de apresentação sem instanciar uma interface visual.
No exemplo hipotético do pedido, o teste verifica o estado exposto após a ação de aplicar o cupom, sem precisar clicar em um botão real.
Na manutenção, a divisão ajuda a localizar a responsabilidade envolvida em uma alteração. Uma mudança restrita aos elementos visuais pode permanecer na View.
Uma mudança na regra do cupom pertence ao Model. Já uma alteração na preparação do resultado para exibição envolve o ViewModel.
Como uma interação percorre os três componentes
Em uma implementação com binding, o fluxo de interação entre View, ViewModel e Model passa pela ação do usuário, pelo processamento no Model e pela atualização do estado exibido.
Considere um exemplo hipotético: uma tela de pedido com o botão “Aplicar cupom”. A sequência abaixo ilustra a divisão de responsabilidades, sem estabelecer uma implementação obrigatória para todas as plataformas.
O usuário informa o cupom e aciona o botão na View.
A View aciona um comando do ViewModel por command binding, a vinculação entre uma ação da interface e um comando.
O ViewModel coordena a ação e solicita ao Model o processamento do cupom.
O Model executa a regra de negócio e retorna os dados do resultado.
O ViewModel atualiza as propriedades usadas pela tela e sinaliza a mudança.
A View reflete o novo estado por data binding e exibe o total atualizado.
Nesse fluxo, a View não calcula o desconto. O ViewModel coordena a solicitação e prepara o resultado para exibição, enquanto a regra do cupom permanece no Model.
No ecossistema .NET, a interface INotifyPropertyChanged é um exemplo de mecanismo para notificar mudanças em propriedades. Ela não é um requisito universal do MVVM: o mecanismo de notificação varia conforme a implementação.
O que o data binding faz nessa comunicação?
O data binding sincroniza a interface com o estado do ViewModel. Em uma vinculação configurada para refletir mudanças, a atualização de uma propriedade se manifesta no elemento correspondente da View.
Essa automatização reduz o código repetitivo necessário para manter a tela consistente com os dados de apresentação. No exemplo do pedido, o total exposto pelo ViewModel é vinculado ao elemento que o exibe.
A ligação entre View e ViewModel por data binding ou implementação manual preserva a distinção entre o padrão e o mecanismo usado para conectá-los. Em ambientes sem binding disponível, a sincronização fica a cargo do código escrito pelo desenvolvedor.
O MVVM é associado ao contexto de aplicações WPF (Windows Presentation Foundation) e ao aproveitamento do data binding. Seu uso não se limita a esse contexto: o padrão também organiza aplicações desktop e mobile que exigem separação de responsabilidades.
Perguntas frequentes sobre MVVM
O que é a estrutura MVVM?
É a organização em Model, View e ViewModel. O Model reúne dados e regras de negócio; a View é a interface; o ViewModel prepara dados e ações para a apresentação. A divisão descreve responsabilidades, não uma lista obrigatória de pastas.
Para que serve o data binding no MVVM?
O data binding mantém a View sincronizada com o estado exposto pelo ViewModel. Ele automatiza essa ligação e reduz o código repetitivo de atualização da interface.
Por que o ViewModel não deve ter referência direta à View?
Para manter a lógica de apresentação separada da interface visual. Sem essa dependência, os testes verificam o estado e as ações do ViewModel sem criar uma tela.
O MVVM exige data binding?
O data binding é o mecanismo tradicional de ligação entre View e ViewModel, mas essa ligação também admite implementação manual. A separação entre negócio, interface e apresentação continua sendo o conceito central.
Em quais tipos de aplicação o MVVM é usado?
O MVVM é usado em aplicações com interface gráfica que exigem separação de responsabilidades, como aplicações desktop e mobile. Os mecanismos de comunicação entre os componentes variam conforme a plataforma e a implementação.
Construa sua carreira em tecnologia com formações alinhadas ao mercado
Se você quer ingressar ou crescer no mercado da tecnologia, a Allevo Tech oferece formações práticas em áreas de alta demanda, como Engenharia de Software, Ciência de Dados e Inteligência Artificial.
As trilhas são estruturadas para desenvolver competências técnicas e preparar você para os desafios do mercado de trabalho.
Clique no botão abaixo e conheça as formações da Allevo Tech que podem impulsionar a sua trajetória profissional.
Ver publicações 
