Validação no CakePHP

Validação no CakePHP: A integridade dos dados é o que separa um sistema profissional de um projeto amador propenso a falhas e vulnerabilidades. Se você já tem suas tabelas conectadas pelas associações que vimos no artigo anterior, agora precisa garantir que ninguém insira um “e-mail” que na verdade é apenas um texto qualquer, ou que um usuário consiga salvar um artigo sem título.

Como especialista em CakePHP, preparei este décimo primeiro artigo para detalhar uma das maiores forças deste framework: a separação clara entre validação de entrada e regras de negócio. Vamos aprender a usar Validation e BuildRules para criar uma blindagem em torno do seu banco de dados.

Validation & BuildRules: Como garantir que apenas dados limpos entrem no banco

Validação no CakePHP: No CakePHP, a proteção dos dados não acontece em um único bloco de código confuso. O framework inteligentemente separa o processo em duas camadas distintas que ocorrem em momentos diferentes do ciclo de vida da requisição.

1. Validation (Validação): Foca no formato e na presença dos dados brutos. (Ex: “Isto é um e-mail válido?”, “Este campo tem pelo menos 10 caracteres?”).
2. BuildRules (Regras de Aplicação): Foca no contexto e no estado do banco de dados. (Ex: “Este e-mail já existe no sistema?”, “Este autor_id realmente existe na tabela de usuários?”).

Dominar essas duas camadas é essencial para manter a sanidade do seu blog e a segurança dos seus dados.

1. A Primeira Linha de Defesa: Validation

A camada de Validation é a primeira a ser executada. No momento em que você usa o método $this->Artigos->patchEntity($entidade, $dados), o CakePHP aciona o validador. Se os dados não passarem por aqui, eles sequer chegam a ser processados para o salvamento.

As validações ficam dentro do seu Table Object (src/Model/Table/ArtigosTable.php), especificamente no método validationDefault.

Exemplo Prático de Validação

PHP

public function validationDefault(Validator $validator): Validator
{
    $validator
        ->integer('id')
        ->allowEmptyString('id', 'create');

    $validator
        ->scalar('titulo')
        ->minLength('titulo', 5, 'O título precisa ter pelo menos 5 caracteres')
        ->maxLength('titulo', 255)
        ->requirePresence('titulo', 'create')
        ->notEmptyString('titulo', 'Por favor, preencha o título do artigo');

    $validator
        ->email('contato_email', false, 'Insira um e-mail válido para contato');

    return $validator;
}

Por que isso é incrível?

Porque o CakePHP usa essas regras para gerar automaticamente mensagens de erro que podem ser exibidas nas suas Views. Se o usuário deixar o campo vazio, o objeto da entidade retornará os erros e o FormHelper cuidará de mostrar o aviso em vermelho para o usuário sem que você precise escrever um único if manual para isso.

2. A Segunda Camada: BuildRules (Regras de Aplicação)

Muitas vezes, um dado pode estar no formato correto (validação OK), mas ser inválido para a sua regra de negócio. Por exemplo: um e-mail está bem formatado, mas ele já pertence a outro usuário.

Diferente da validação, as BuildRules são verificadas apenas no momento do save(). Elas dependem do acesso ao banco de dados para conferir a integridade.

Exemplo de Regras de Aplicação

PHP

use Cake\ORM\RulesChecker;

public function buildRules(RulesChecker $rules): RulesChecker
{
    // Garante que o e-mail seja único na tabela
    $rules->add($rules->isUnique(['email'], 'Este e-mail já está cadastrado.'));

    // Garante que o categoria_id fornecido realmente exista na tabela Categorias
    $rules->add($rules->existsIn(['categoria_id'], 'Categorias', 'A categoria selecionada não é válida.'));

    return $rules;
}

A Diferença Vital:

Enquanto o Validator verifica a “forma”, o RulesChecker verifica o “contexto”. Se você tentar salvar um artigo com uma categoria_id que não existe, o validador deixará passar (pois é um número inteiro válido), mas a BuildRules impedirá o salvamento para evitar um erro de integridade referencial no MySQL.

3. Criando Validações Customizadas

O CakePHP já vem com dezenas de validações prontas (e-mail, cartões de crédito, upload de arquivos, datas, etc.). Mas e se você precisar de algo muito específico, como validar um CPF ou uma regra própria?

Você pode criar métodos de validação personalizados diretamente no seu Table Object:

PHP

$validator->add('slug', 'custom', [
    'rule' => function ($value, $context) {
        // Regra: o slug não pode conter a palavra "teste"
        return strpos($value, 'teste') === false;
    },
    'message' => 'O slug não pode conter termos de teste.'
]);

4. Múltiplos Conjuntos de Validação

Uma das maiores dores de cabeça em outros frameworks é quando você precisa de validações diferentes para a mesma tabela. Por exemplo: no cadastro rápido do blog, você só pede o e-mail; no perfil completo, você exige endereço e CPF.

No CakePHP, você pode criar métodos como validationPerfilCompleto e chamá-los no Controller:

PHP

// No Controller
$artigo = $this->Artigos->patchEntity($artigo, $this->request->getData(), [
    'validate' => 'perfilCompleto'
]);

Isso dá uma flexibilidade absurda ao seu sistema, permitindo que a mesma Model se comporte de formas diferentes dependendo da situação.

5. Onde os Erros Aparecem?

Quando a validação ou as regras falham, o método save() retorna false. Mas onde estão os erros? Eles ficam guardados dentro da própria Entity.

PHP

if ($this->Artigos->save($artigo)) {
    // Sucesso
} else {
    // Para ver os erros no debug:
    debug($artigo->getErrors());
}

O CakePHP mapeia esses erros campo a campo. O FormHelper nas suas Views lê esse array de erros e anexa as mensagens diretamente abaixo dos inputs correspondentes.

6. Boas Práticas para Dados Limpos

Para garantir que seu blog de 500 artigos e seus projetos SaaS sejam blindados, siga estas diretrizes:

1. Não confie no Front-end: Validações em JavaScript são ótimas para a experiência do usuário, mas nunca substituem a validação no PHP (Server-side).
2. Use a camada de Model: Nunca faça validações manuais dentro do Controller. Isso quebra o padrão MVC e dificulta a manutenção.
3. Aproveite a Convenção: Se você definiu um campo como NOT NULL no banco de dados via Migrations, o Bake já gerará as validações básicas de notEmpty para você.
4. Limpeza antes da Validação: Use o recurso de _beforeMarshal no Table para limpar dados (como remover máscaras de CPF ou formatar strings) antes que o validador entre em ação.

Conclusão: Segurança que Gera Tranquilidade

Validação no CakePHP: Entender a distinção entre Validation e BuildRules é o que transforma você em um desenvolvedor CakePHP de elite. Ao delegar a responsabilidade de “limpeza” e “integridade” para a Model, seu Controller fica magro e sua aplicação se torna previsível e segura.

Dados limpos significam menos bugs em produção, relatórios mais precisos e, acima de tudo, uma experiência de uso confiável para os internautas do seu blog. Você não está apenas salvando dados; você está protegendo o patrimônio de informação do seu projeto.

Mas antes de dominar o CakePHP, se for o seu caso, toda jornada tem um início. Vamos entender quais são os conhecimentos básicos necessários para aproveitar ao máximo este poderoso framework. Para iniciar seus estudos no CakePHP, você precisará dominar as seguintes tecnologias:

E se você gosta do nosso conteúdo, não deixe de contribuir adquirindo os serviços e produtos dos nossos apoiadores e empresas que somos associados.

Agora que seus dados estão validados e seguros, é hora de aprender a otimizar a lógica que processa essas informações. No próximo artigo, veremos: “Request & Response: Manipulando dados de entrada e cabeçalhos.”

Dica de Especialista: Sempre que uma regra de negócio envolver comparação de dados entre tabelas diferentes, prefira usar BuildRules. Se a regra for apenas sobre o formato do dado isolado, use Validation. Essa separação deixará seus testes unitários muito mais fáceis de escrever no futuro!