O padrão arquitetônico de Model-View-Controller (MVC) tem sido há muito tempo uma pedra angular do desenvolvimento estruturado de aplicações web. Ao separar uma aplicação em três componentes interligados – Modelo (dados e lógica de negócios), Visualização (interface de usuário) e Controlador (manutenção de entrada) – OMVC promove código organizado que é mais fácil de manter, testar e estender. Mesmo dentro desta separação clara, os desenvolvedores frequentemente encontram atritos: os dados brutos do modelo de domínio raramente se encaixam na forma exata exigida pela visão, e a lógica de apresentação tende a vazar em controladores ou visualizações, criando um código confuso e difícil de manter. É aqui que o padrão ViewModel se torna indispensável. Um ViewModel atua como um intermediário adaptado que simplifica a vinculação de dados e centraliza a lógica de apresentação, permitindo que a arquitetura MVC cumpra sua promessa de separação limpa e de manutenção de código.

O que é um modelo de visão?

Um ViewModel é uma classe personalizada desenhada especificamente para atender às necessidades de dados e comportamento de uma visão particular. Ele se situa entre o Modelo (o domínio ou camada de acesso de dados) e a Visão, transformando dados brutos em uma forma que a visão pode consumir sem esforço. Ao contrário do modelo de domínio, que representa entidades de negócios e regras (por exemplo, um objeto com , , , e , um ViewModel pode conter apenas os campos necessários para essa visão – talvez ] (uma propriedade calculada), , ou uma lista de . Ele também achata gráficos de objetos complexos para impedir que a visão precise de navegar cadeias de relacionamento.

Considere uma página de perfil de usuário típica. O modelo de domínio pode ter separado e . Um poderia combinar o nome, a cidade e o estado do usuário em uma única string , e apresentar a data de junção em um formato legível para humanos. Sem um ViewModel, a visualização precisaria entender a estrutura de ambas as entidades e executar a lógica de formatação – uma clara violação da separação de preocupações.

ViewModel vs. Modelo de Domínio vs. DTO

É importante distinguir um ViewModel de outros padrões semelhantes. Um objeto de transferência de dados (DTO) é frequentemente usado para mover dados entre camadas (por exemplo, de um serviço para um controlador) e geralmente não possui comportamento. Um ViewModel, por outro lado, é específico para visualização e pode incluir lógica de apresentação, atributos de validação e gerenciamento de estado (por exemplo, é o usuário em modo de edição?). Em contraste, o modelo de domínio contém regras de negócios e invariantes; você nunca deve expor modelos de domínio diretamente para visualizações, já que casais sua interface de usuário para sua camada de negócios e pode levar a problemas de segurança e manutenção.

Como VerModelos Simplificar a Ligação de Dados

A ligação de dados é o mecanismo que liga elementos de UI a fontes de dados, sincronizando automaticamente valores. Em frameworks MVC do lado do servidor como ASP.NET MVC, Spring MVC ou Laravel, a ligação de dados ocorre normalmente durante as submissões de formulários: o framework lê parâmetros de solicitação HTTP e mapeia-os para um objeto modelo. Quando esse objeto é um ViewModel, o mapeamento torna-se simples e seguro.

Usar um ViewModel para a vinculação de dados oferece várias vantagens:

  • Mapeamento preciso dos campos de formulário:] Você pode definir exatamente quais campos a visualização espera, evitando ataques de excesso de postagem onde um usuário malicioso injeta campos extras (por exemplo, definindo ] em um formulário de registro). ViewModels agem como uma lista branca.
  • Atributos de validação com type forte: ViewModels permitem que você coloque regras de validação (como , , ou validadores personalizados) diretamente nas propriedades que a view renderiza. Isso centraliza a lógica de validação e permite a validação tanto do lado cliente quanto do servidor perfeitamente.
  • Reduzidos erros de ligação: Porque o ViewModel mapeia one-to-one com o formulário UI, os desenvolvedores evitam o cálculo de parâmetros de solicitação correspondentes a gráficos de objetos complexos. Isto reduz os erros de ligação e reduz o código da placa de caldeira em controladores.

Exemplo: Formulário de Registro do Usuário

Sem um ViewModel, um controlador pode vincular uma solicitação de registro a um modelo de domínio com campos como e que o formulário nunca deve ser definido. Com um contendo apenas , , e , o controlador pode ligar, validar e mapear com segurança o ViewModel para o modelo de domínio dentro da lógica de negócio. Isto mantém o controlador magro e o modelo de domínio protegido.

Em frameworks de cliente que usam a ligação bidirecional (por exemplo, Angular ou Vue.js), ViewModels servem um papel semelhante definindo a forma dos dados que os componentes irão exibir e modificar. O ViewModel pode incluir propriedades computadas, rastreamento de mudanças e manipuladores de eventos, todos eles encapsulados e testáveis.

Papel dos Modelos de Visualização na Lógica de Apresentação

A lógica de apresentação engloba tudo o que a visão precisa fazer com os dados: datas de formatação, conversão de moeda, concatenação de nomes, cálculo de totais, decisão de quais seções mostrar com base em permissões do usuário, e gerenciamento de estado de UI (por exemplo, “Loading” vs. “Erro”). Sem ViewModels, esta lógica muitas vezes termina na visualização (usando funções de helper ou formatação em linha) ou no controlador (tornando-a intestável e inchada). ViewModels centraliza esta lógica em uma classe dedicada e testável.

Por exemplo, uma visão de detalhes de ordem pode precisar exibir:

  • Data de pedido em um formato amigável (“15 de março de 2025”)
  • Nome completo do cliente (combinado do primeiro e último)
  • Cada linha com um subtotal (quantidade × preço unitário)
  • Ordem total com impostos e envio
  • Se a ordem é elegível para cancelamento (com base no estado e no tempo decorrido)

Todas essas transformações pertencem ao ViewModel. A visão simplesmente renderiza propriedades como , , ] (cada um ] com , e . O controlador cria o ViewModel recuperando o modelo de domínio da camada de serviço, mapeando-o e passando-o para a vista.

Agregando Dados de Várias Fontes

Outra necessidade comum é exibir dados de vários modelos de domínio em uma página. Um painel pode combinar dados de perfil de usuário, pedidos recentes e notificações. Um ViewModel pode manter todas essas peças em um único objeto, facilitando a visualização para renderizar uma página coesa. O controlador chama serviços separados e monta o ViewModel, o que impede que a visualização tenha que entender várias fontes de dados.

Benefícios de Usar Modelos de Visualização

As vantagens de aplicar consistentemente o padrão ViewModel são substanciais e impactam diretamente a qualidade do código, a manutenção e a produtividade da equipe.

Separação de preocupações melhorada

ViewModels impõe um limite limpo entre a camada de domínio (regras de negócio) e a camada de apresentação. Alterações na interface (como adicionar um novo campo a um formulário) requerem alterações apenas no VisualizadorModelo e visualização, não no modelo de domínio. Por outro lado, alterações no modelo de domínio (como uma nova propriedade em uma entidade) não ondulam para a visualização, a menos que você atualize o mapeamento do ViewModel. Este isolamento reduz o risco de regressão.

Melhora da comprovabilidade da lógica da UI

A lógica de apresentação em visualizações é notoriamente difícil de unir testes. Com o ViewModels, você pode testar a formatação, agregação e gerenciamento de estado em isolamento da estrutura de UI. Você pode escrever testes unitários que verificam ou sem carregar um navegador ou renderizar HTML. Isso leva a feedback mais rápido e código mais confiável.

Duplicação de Código Reduzida

Quando os mesmos dados devem ser exibidos em várias visualizações (por exemplo, uma placa de produto em uma lista e em uma página de detalhes), você pode criar uma classe comum do ViewModel que ambas as visualizações usam. A lógica de apresentação vive em um lugar em vez de ser copiada em cada visualização. Isso também torna as mudanças de UX mais fáceis de propagar.

Melhor organização de dados específicos para apresentação

ViewModels armazena o estado de UI, como “modo de edição”, “mostrar erros” ou “número de página”. Isso mantém a visão sem estado e o controlador focado na navegação. Com frameworks que suportam a ligação ao modelo, você também pode serializar o estado ViewModel através de requisições, permitindo interações ricas como assistentes multi-passo.

Pistas e melhores práticas comuns

Mesmo com seus benefícios, o padrão ViewModel pode ser mal aplicado. Aqui estão erros comuns e como evitá-los.

Modelos de Vista Sobreusados para Todas as Vistas

Nem todas as visões precisam de um ViewModel personalizado. Para páginas simples que correspondem a um único objeto de domínio, vincular diretamente a um DTO (ou mesmo o modelo de domínio se você usar uma camada somente de leitura) pode ser aceitável. A regra de ouro: se você se encontrar adicionando formatação ou combinando propriedades, é hora de um ViewModel. Use julgamento — criando um ViewModel para cada visualização parcial minúscula pode inchar a base de código.

Modelos de Visualização Anêmica

Um ViewModel que não passa de um saco de propriedades públicas sem comportamento pode levar a uma fuga de lógica noutro lugar. Inclua métodos de ajuda ou propriedades computadas que encapsulam a lógica de apresentação (por exemplo, )]). Isto mantém a lógica no ViewModel onde ela pertence.

Convenções de nomeação

Visualização de NomeModelos explicitamente para indicar o seu propósito. Use sufixos como (por exemplo, ) ou nomes mais específicos como se for usado para submissão de formulários. Evite nomes genéricos como essa intenção obscura. Organize consistentemente ViewModelos em uma pasta separada (por exemplo, ]] na ASP.NET MVC) para manter a estrutura do projeto limpa.

Mapeamento entre o domínio e o modelo de visualização

O mapeamento manual (propriedade por propriedade) é tedioso e propensa a erros. Use uma ferramenta como AutoMapper para .NET, MapStruct para Java ou funções auxiliares no PHP para automatizar o mapeamento. No entanto, tenha cuidado para não mapear cegamente—às vezes a estrutura ViewModel difere significativamente do domínio, e o mapeamento manual oferece clareza. Automatize os mapeamentos diretos, mas não hesite em escrever lógica explícita para transformações complexas.

Implementação de Modelos de Visualização em Frameworks

Os princípios são universais, mas as implementações diferem ligeiramente. Vejamos três quadros populares de MVC.

ASP.NET MVC / Núcleo

No ASP.NET MVC, ViewModels são classes simples de C# colocadas em uma pasta . Controladores os recebem através de parâmetros de método de ação usando atributos ou vinculação de modelos de visualização. As visualizações Razor são digitadas fortemente no ViewModel (). O framework suporta atributos de validação diretamente nas propriedades ViewModel. ViewModels também são usados para exibir dados; o controlador retorna . Por exemplo:

public class UserProfileViewModel
{
 public int Id { get; set; }
 [Display(Name = "Full Name")]
 public string FullName { get; set; }
 public string Email { get; set; }
 [DataType(DataType.Date)]
 public DateTime JoinedDate { get; set; }
}

Saiba mais sobre ViewModels in ASP.NET Core a partir de Documentação oficial da Microsoft.

Primavera MVC (Java)

Na Primavera MVC, ViewModels são frequentemente chamados de “objects de apoio de forma” ou “objects de comando”. São POJOs Java simples com anotações de validação (como , ]). O controlador usa para ligar os dados do formulário ao ViewModel. Para fins de visualização, você pode colocar dados no modelo via ] e depois referí- los nos modelos JSP ou Thymeleaf. A Primavera também suporta ] para editores de propriedades personalizados.

Laravel (PHP)

Laravel não tem classes de ViewModel incorporadas, mas encoraja o padrão através de requisições de formulário (validação) e classes de recursos (respostas API). Para ver as áreas renderizadas por servidor, você pode criar classes personalizadas ou simplesmente passar um array. No entanto, usando classes dedicadas de ViewModel (por exemplo, ]) melhora a segurança e a testabilidade do tipo. Os modelos de Laravel podem receber uma instância e acessar seus métodos. Veja A documentação de solicitação de formulário de Laravel] para separação de validação.

Padrões Avançados de Modelo de Visualização

À medida que as aplicações crescem, você pode precisar de estruturas mais sofisticadas do ViewModel.

Modelos de Visualização Aninhados

Quando uma visualização contém uma lista de itens, crie um modelo de visualização pai segurando uma coleção de modelos de visualização de crianças. Por exemplo, um pode conter e . Cada criança ViewModel tem sua própria lógica de apresentação.

VerModelo Herança e Composição

Se várias visualizações compartilham propriedades comuns (por exemplo, uma seção de "cabeçalho de página" com informações do usuário e itens de menu), você pode criar uma classe base ViewModel e extendê-la. Alternativamente, use a composição: inclua uma propriedade . A composição é muitas vezes mais flexível e evita hierarquias de herança profundas.

ViewModels com Inicialização Assíncrona

Alguns ViewModels requerem dados de chamadas assync (por exemplo, APIs externas). Você pode criar um método de fábrica ou um serviço dedicado que constrói o ViewModel assincronicamente. O controlador aguarda a fábrica e passa o resultado para a visualização. Isto mantém o controlador síncrono e testável, permitindo que o ViewModel seja povoado assíncronamente.

Conclusão

ViewModels são uma ferramenta poderosa, mas muitas vezes subutilizada, no desenvolvimento de MVC. Ao servir como um intermediário personalizado entre modelos e visualizações, eles simplificam a vinculação de dados, centralizam a lógica de apresentação e impõem uma separação limpa de preocupações. Eles protegem modelos de domínio de mudanças específicas de interface, melhoram a testabilidade, reduzem a duplicação e tornam a base de código mais mantendível à medida que a aplicação evolui. Se você está construindo uma pequena ferramenta interna ou uma grande aplicação empresarial, investir tempo na criação de ViewModels pensativo paga dividendos em qualidade de código e produtividade do desenvolvedor.

Ao implementar ViewModels, lembre-se de mantê-los magros e expressivos, alavancar atributos de validação e usar ferramentas de mapeamento criteriosamente. Evite a armadilha de fazer cada visualização depender de um ViewModel – use-os onde eles adicionam valor. A disciplina de projetar ViewModels irá aguçar sua compreensão das verdadeiras necessidades de sua interface e levar a aplicativos MVC mais limpos e robustos. Para mais leitura, veja a discussão de Martin Fowler sobre Modelo de Apresentação, um padrão intimamente relacionado com ViewModels, e a visão geral da arquitetura MVC Microsoft para uma visão abrangente do padrão em ASP.NET.