Quando você está começando, “validar” parece uma coisa só: verificar se o usuário preencheu tudo certo.
Mas conforme o sistema cresce, você percebe que validação não é só “campo obrigatório”.
Validar é garantir que:
- o sistema não quebre com dados ruins
- o sistema não aceite coisas que não deveriam ser permitidas
- o sistema siga as regras do seu próprio negócio
E aí vem a dúvida clássica:
No MVC, onde eu coloco as validações: Controller, Model ou Service?
A resposta mais útil para iniciantes é: depende do tipo de validação. Vamos simplificar isso de um jeito prático.
Antes de tudo: o que é “validação”?
Validação é qualquer checagem que responde:
- “Isso está preenchido corretamente?”
- “Isso faz sentido?”
- “Isso é permitido?”
Se a resposta for “não” para qualquer uma das opções acima, você precisa bloquear a ação e informar o erro.
O erro mais comum de iniciantes no MVC
Acontece muito isto:
- Controller valida “um pouco”
- View valida “um pouco” (com JavaScript)
- Model valida “um pouco”
- Uma library valida “mais um pouco”
Resultado: regra duplicada e confusa
O objetivo deste post é você sair com um mapa simples:
- qual validação vai para qual lugar
- por que isso melhora seu projeto
- como evitar retrabalho e bagunça
Leitura recomendada
Se você ainda está aprendendo a base do MVC, recomendo ler primeiro este post:
MVC: Entenda de Verdade Model, View e Controller (e Onde Entram Libraries, Helpers e Services)
Os 2 tipos de validação que você PRECISA separar
Para iniciante, o mais importante é aprender esta divisão:
- Validação de entrada (request/formulário)
- Validação de regra do sistema (regra de negócio)
Só isso já resolve 80% da confusão.
1) Validação de entrada: “o dado chegou minimamente certo?”
Essa validação é a mais básica e normalmente vem de formulário.
Exemplos comuns:
- campo obrigatório vazio
- e-mail em formato inválido
- número que veio como texto (“abc”)
- data em formato errado
- senha muito curta
Perceba: isso não é “regra do seu sistema”.
É o mínimo para o sistema conseguir trabalhar com os dados.
Onde colocar?
No Controller (ou na camada que recebe a requisição).
Por quê?
é ali que o dado entra, você barra cedo e devolve resposta rápida e evita chamar outras partes do sistema com algo quebrado.
E o JavaScript no navegador?
Ele ajuda muito na experiência do usuário (não deixar enviar vazio, por exemplo), mas atenção:
- validação do front-end é conforto
- validação do back-end é segurança
Ou seja: se você validar no navegador, ótimo.
Mas o sistema precisa validar de verdade no servidor também.
2) Validação de regra do sistema: “isso pode acontecer no meu sistema?”
Aqui está a diferença principal.
Regra do sistema é o que define “o que é permitido” de acordo com o seu projeto.
Exemplos comuns:
- “não pode cadastrar e-mail que já existe”
- “não pode registrar movimentação com valor negativo”
- “não pode finalizar pedido sem itens”
- “não pode apagar um item que já foi faturado”
- “não pode agendar um serviço no passado (se essa for a regra)”
Perceba: isso pode depender de outras coisas:
- dados existentes
- estado atual do registro
- regras internas do seu projeto
Onde colocar?
No Service (recomendado) ou no Model (no sentido de “regra do domínio”).
Por quê?
A regra precisa valer independente da tela, hoje você pode ter formulário; amanhã pode ter API, importação, automação, se a regra está só no Controller, você corre risco de duplicar em vários lugares.
A regra “de verdade” deve morar onde o sistema “pensa”.
Por que o Service costuma ser o melhor lugar (para iniciantes)
Se você tenta colocar todas as regras no Controller, ele vira um monstro.
Se você tenta colocar todas as regras no Model do framework, às vezes ele fica preso demais ao banco.
O Service é um ótimo meio termo para começar bem:
Controller fica simples: recebe → chama → responde
Service fica responsável pela ação: valida regras → executa → retorna resultado
Você passa a ter algo como:
- Controller: “Recebi o pedido”
- Service: “Vou aplicar as regras e executar”
- Model: “Vou salvar/buscar dados”
E se eu já coloco regra numa “library”? Está errado?
Não necessariamente, mas pode virar bagunça rápido.
Uma boa regra para iniciantes é:
Helpers: funções pequenas e genéricas (formatação, string, data, etc.)
Libraries: recursos técnicos reutilizáveis (e-mail, integração, upload, etc.)
Services: tarefas do sistema e regras do sistema (casos de uso)
Se a “library” está cheia de regra do seu sistema (“calcular parcela do seu app”, “validar estado do seu pedido”), ela está se comportando como um service, só com outro nome.
O problema não é o nome em si. É a organização.
Mas acertar o nome ajuda você (e outras pessoas) a entender o projeto mais rápido.
Checklist rápido: onde coloco esta validação?
Use este guia rápido:
Se a validação é sobre o formato do dado (campo, tipo, obrigatoriedade):
→ Controller
Se a validação é sobre a regra do sistema (permitido ou não permitido):
→ Service/Model
Se é só para melhorar a experiência do usuário (antes de enviar):
→ front-end (mas nunca sozinho)
Se é proteção estrutural (ex.: campo único, integridade):
→ banco ajuda como “última barreira”, mas não substitui as regras no sistema
Como mostrar erros na tela sem bagunçar o MVC
Uma dica importante:
quem valida (Controller/Service/Model) devolve uma lista de erros, a View só exibe.
Isso evita a View “inventar regra” e mantém a tela simples.
Conclusão
Para iniciantes, a forma mais segura e fácil de aplicar validações no MVC é:
Controller: validação de entrada (o mínimo do que chegou)
Service/Model: validação de regra do sistema (o que pode ou não pode acontecer)
View: apenas exibe mensagens e dados
Essa separação evita duplicação, reduz bugs e facilita a evolução do projeto.