DEV Community: Denis Augusto

Seu controller tá fazendo o trabalho do Form Request (e ele não devia)

Denis Augusto — Fri, 26 Jun 2026 15:42:12 +0000

Abre o seu controller. Vai, eu espero

Tem um método store() aí dentro com umas 40 linhas? Começando com um $request->validate([...]) gigante, seguido de um monte de if, depois a regra de negócio, depois o retorno?

Pois é. Seu controller tá fazendo um trabalho que não é dele.

A função de um controller é simples: receber a requisição, chamar quem resolve o problema, devolver a resposta. Ele é o garçom, não o cozinheiro. E ainda assim a gente vive enfiando validação, autorização e tratamento de dados ali no meio, até virar aquele monstrinho de 80 linhas que ninguém quer abrir na sexta-feira.

Já viu (ou escreveu) isso? Senta aí que tem solução, e ela já vem de fábrica no Laravel.

O controller-faz-tudo

Olha esse clássico:

public function store(Request $request)
{
    $validated = $request->validate([
        'titulo'    => 'required|string|max:255',
        'conteudo'  => 'required|string|min:10',
        'categoria' => 'required|exists:categorias,id',
    ]);

    if (! $request->user()->can('criar-post')) {
        abort(403);
    }

    $validated['slug'] = Str::slug($validated['titulo']);

    $post = Post::create($validated);

    return redirect()->route('posts.show', $post);
}

Funciona? Funciona. Mas repara quantas responsabilidades diferentes tão espremidas aí: validação, autorização, transformação de dado e a regra de negócio de verdade. Tudo no mesmo lugar.

Agora imagina esse mesmo bloco repetido no update(). E na versão da API. Copiado, colado, com pequenas diferenças. De novo a velha história.

O controller tem UMA função

Existe um princípio chamado Single Responsibility: cada classe deveria ter um motivo só pra mudar. O controller muda quando o fluxo da requisição muda — não quando uma regra de validação muda, não quando uma permissão muda.

Validação é um conhecimento. Autorização é outro. Cada um merece morar na sua própria casa, e o Laravel já construiu essa casa pra você: o Form Request.

A solução: tira o peso do controller

Gera com um comando:

php artisan make:request StorePostRequest

Isso cria app/Http/Requests/StorePostRequest.php. Joga tudo que não é função de controller pra dentro dele:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Support\Str;

class StorePostRequest extends FormRequest
{
    // Autorização: este usuário pode fazer isso?
    public function authorize(): bool
    {
        return $this->user()->can('criar-post');
    }

    // Validação: os dados estão corretos?
    public function rules(): array
    {
        return [
            'titulo'    => ['required', 'string', 'max:255'],
            'conteudo'  => ['required', 'string', 'min:10'],
            'categoria' => ['required', 'exists:categorias,id'],
        ];
    }

    // Preparação: ajusta os dados ANTES de validar
    protected function prepareForValidation(): void
    {
        $this->merge([
            'slug' => Str::slug($this->titulo),
        ]);
    }
}

E agora olha o que sobrou do controller:

public function store(StorePostRequest $request)
{
    $post = Post::create($request->validated());

    return redirect()->route('posts.show', $post);
}

Duas linhas. Duas. O controller voltou a ser garçom.

O pulo do gato é o type-hint: ao trocar Request por StorePostRequest, o Laravel roda a autorização e a validação automaticamente antes do método executar. Falhou? Nem entra no store(). O usuário já recebe o erro certo, redirecionado de volta, com as mensagens preenchidas.

Form Request não é só `rules()`

Esse é o ponto que quase ninguém usa direito. O Form Request tem três super-poderes, não um:

Autorização — o authorize() decide quem pode. Retornou false, vira 403 sozinho:

public function authorize(): bool
{
    return $this->user()->id === $this->route('post')->user_id;
}

Mensagens customizadas — sem espalhar texto pelo projeto:

public function messages(): array
{
    return [
        'titulo.required' => 'O título é obrigatório, capricha nele.',
        'conteudo.min'    => 'Conteúdo muito curto, conta mais história.',
    ];
}

Preparação de dados — o prepareForValidation() ajusta a entrada antes da regra rodar. Ótimo pra normalizar CPF, gerar slug, limpar máscara de telefone.

Tudo isso saiu do controller e foi morar onde faz sentido.

Pausa: e quando NÃO usar?

Porque sim, dá pra exagerar. Form Request vira muleta quando você cria um pra toda e qualquer rota, mesmo as triviais.

Tem um endpoint que valida só um campo? Um filtro de busca com um q opcional? Criar uma classe inteira pra isso é cerimônia demais. Um $request->validate(['q' => 'nullable|string']) ali mesmo resolve e é mais legível.

A régua é simples: se a validação é curta, usada num lugar só e não tem autorização envolvida, deixa inline. Se ela cresce, se repete, ou se mistura validação com permissão — chama o Form Request. Ele existe pra tirar peso, não pra adicionar burocracia.

E mais um aviso: Form Request não é lugar de regra de negócio. Calcular preço, disparar evento, mexer em outras tabelas — isso é trabalho da camada de serviço, não da validação. Não troque um controller inchado por um Form Request inchado.

Bônus: olha quantos controllers seus pedem isso

Pega seu projeto e procura por $request->validate(. Quantos resultados? Cada um daqueles, especialmente os que se repetem entre store e update, é um Form Request esperando pra nascer.

Começa pelo controller mais bagunçado que você tem. Extrai um. Vê como ele encolhe. Vicia.

Antes de você fechar a aba

Pergunta sincera: qual é o controller mais inchado do seu projeto hoje? Aquele que você sente um arrepio só de abrir.

Comenta aí embaixo o tamanho do método store() mais cabeludo que você já viu (ou escreveu, sem vergonha). E se esse post te deu vontade de fazer um refactor agora, salva ele e manda pro colega que ainda valida tudo no controller.

Seu controller magro agradece. 😄

Seu código de validação de CPF tá gritando por socorro (e você nem percebeu)

Denis Augusto — Fri, 26 Jun 2026 15:37:27 +0000

Deixa eu adivinhar.

Você tá com um projeto Laravel rodando, tem uns 5, 10, talvez 15 formulários que recebem CPF. Cadastro de cliente, cadastro de fornecedor, atualização de perfil, checkout, área administrativa… e em cada um desses lugares tem aquela mesma lógica de validação de CPF. Copiada. Colada. Com pequenas variações.

E tá tudo bem. Até o dia em que o cliente pede pra mudar uma regra. Ou um bug aparece em um formulário e funciona normal no outro. Aí você abre o projeto, dá um Ctrl+Shift+F procurando "cpf" e… surpresa: tem oito lugares diferentes com a mesma validação. Com mensagens de erro escritas de oito jeitos. Uma delas até com erro de digitação.

Já passou por isso? Então senta que essa conversa é pra você.

O crime acontecendo em câmera lenta

Olha esse cenário aqui, que eu garanto que você já viu (ou escreveu):

// app/Http/Requests/StoreClienteRequest.php
public function rules()
{
    return [
        'cpf' => ['required', function ($attribute, $value, $fail) {
            $cpf = preg_replace('/[^0-9]/', '', $value);
            if (strlen($cpf) !== 11) {
                $fail('CPF inválido.');
                return;
            }
            // ... mais 20 linhas do algoritmo
        }],
    ];
}

E aí, três dias depois, no outro Form Request:

// app/Http/Requests/StoreFornecedorRequest.php
public function rules()
{
    return [
        'cpf' => ['required', function ($attribute, $value, $fail) {
            $cpf = preg_replace('/[^0-9]/', '', $value);
            if (strlen($cpf) !== 11) {
                $fail('O CPF informado não é válido!');  // mensagem diferente, claro
                return;
            }
            // ... mais 20 linhas quase iguais, mas não exatamente
        }],
    ];
}

Multiplica isso por 8 telas. Agora imagina o seu "eu do futuro" tentando manter isso.

Dá pra sentir a dor daqui.

DRY: a sigla que vai salvar seu projeto (e sua sanidade)

DRY significa Don't Repeat Yourself. Em bom português: não se repita, caramba.

A ideia é simples: cada pedaço de conhecimento (uma regra de negócio, um cálculo, uma validação) deve existir em um único lugar no seu sistema. Se precisar mudar, você muda em um lugar só, e todo o resto continua funcionando.

No nosso caso, a "regra de validar CPF" é um conhecimento. E esse conhecimento merece ter um endereço fixo no seu projeto, não ficar espalhado igual confete depois do Carnaval.

E se eu te dissesse que o Laravel já resolveu isso pra você?

O Laravel tem um recurso chamado Custom Validation Rule. É basicamente uma classe que encapsula uma regra de validação. Você escreve uma vez, usa em qualquer lugar.

Gera com um comando:

php artisan make:rule Cpf

Isso cria o arquivo app/Rules/Cpf.php. Abre ele e coloca o algoritmo de validação ali dentro:

<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;

class Cpf implements ValidationRule
{
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        // Tira tudo que não é número
        $cpf = preg_replace('/[^0-9]/', '', (string) $value);

        // CPF tem 11 dígitos. Ponto.
        if (strlen($cpf) !== 11) {
            $fail('O :attribute informado não é um CPF válido.');
            return;
        }

        // Rejeita sequências repetidas (111.111.111-11, 222.222.222-22, etc)
        if (preg_match('/(\d)\1{10}/', $cpf)) {
            $fail('O :attribute informado não é um CPF válido.');
            return;
        }

        // Calcula os dois dígitos verificadores
        for ($t = 9; $t < 11; $t++) {
            $d = 0;
            for ($c = 0; $c < $t; $c++) {
                $d += $cpf[$c] * (($t + 1) - $c);
            }
            $d = ((10 * $d) % 11) % 10;

            if ($cpf[$c] != $d) {
                $fail('O :attribute informado não é um CPF válido.');
                return;
            }
        }
    }
}

Pronto. Acabou. Esse é o único lugar do seu projeto que sabe validar CPF.

Usando na prática

Agora vem a parte boa. Você usa essa Rule em qualquer lugar, com uma linha:

Em um Form Request:

use App\Rules\Cpf;

public function rules()
{
    return [
        'cpf' => ['required', new Cpf()],
    ];
}

Inline no controller:

$request->validate([
    'cpf' => ['required', new Cpf()],
]);

Com Validator facade:

Validator::make($request->all(), [
    'cpf' => ['required', new Cpf()],
])->validate();

Mesmo código. Mesma mensagem de erro. Mesmo comportamento. Em todo lugar.

Mudou a regra? Mexe no app/Rules/Cpf.php. Pronto, mudou em todo lugar.

Pausa rápida: Rule não é Role

Detalhe que confunde muita gente (e tudo bem, eu também já confundi):

Rule = regra de validação. É disso que a gente tá falando.
Role = papel de usuário, ligado a permissões e autorização (tipo "admin", "editor", "cliente").

São coisas completamente diferentes, só têm nome parecido. Se você buscou no Google "Laravel Role validação" e tava perdido, agora sabe o porquê. 😄

Bônus: e agora?

Pegou a ideia? Então olha quantas outras validações no seu projeto provavelmente tão duplicadas:

CNPJ
Telefone (com DDD, formato brasileiro)
CEP
Data de nascimento (maioridade, idade mínima, etc)
Placa de veículo
Cartão de crédito

Cada uma dessas é uma Rule esperando pra nascer. Que tal escolher uma e criar agora? Lição de casa rápida pra quando você terminar de ler isso aqui.

Antes de você fechar a aba

Aqui vai uma pergunta sincera: qual validação você ainda mantém copiada e colada no seu projeto Laravel?

Comenta aí embaixo. Eu juro que não vou julgar (eu mesmo tenho um projeto antigo que precisa urgentemente desse refactor).

E se esse post te poupou de uma dor de cabeça futura, salva ele, compartilha com aquele dev que tá começando agora, ou manda pro seu colega de equipe que tá com 14 controllers validando CPF do jeito errado.

Seu eu do futuro agradece. Seu projeto, também.

Curtiu? Tem mais conteúdo sobre Laravel, boas práticas e como deixar seu código mais limpo por aqui. Me segue pra não perder os próximos.

DEV Community: Denis Augusto

Seu controller tá fazendo o trabalho do Form Request (e ele não devia)

Abre o seu controller. Vai, eu espero

O controller-faz-tudo

O controller tem UMA função

A solução: tira o peso do controller

Form Request não é só rules()

Pausa: e quando NÃO usar?

Bônus: olha quantos controllers seus pedem isso

Antes de você fechar a aba

Seu código de validação de CPF tá gritando por socorro (e você nem percebeu)

O crime acontecendo em câmera lenta

DRY: a sigla que vai salvar seu projeto (e sua sanidade)

E se eu te dissesse que o Laravel já resolveu isso pra você?

Usando na prática

Pausa rápida: Rule não é Role

Bônus: e agora?

Antes de você fechar a aba

Form Request não é só `rules()`