Pare de usar isEmpty() e isBlank() em seus Controllers Spring Boot

#java #webdev #springboot #architecture

É comum encontrarmos em projetos Spring Boot validações como isEmpty(), != null ou isBlank() aplicadas diretamente nos métodos dos Controllers. Embora pareça uma solução rápida, essa prática é um code smell que compromete a escalabilidade e a manutenção do software.

Neste artigo, vamos entender por que você deve evitar essa abordagem e quais são as alternativas alinhadas às boas práticas de engenharia de software.

O problema da lógica no Controller

O papel fundamental de um Controller, seguindo princípios de Clean Architecture e MVC, é a orquestração: receber a requisição, realizar o unmarshalling dos dados e delegar a execução para a camada de serviço ou domínio.

Quando inserimos verificações manuais de strings ou nulidade no Controller, ferimos diversos princípios:

1 - Violação do SRP (Single Responsibility Principle): O Controller passa a acumular responsabilidades de validação e decisão que não lhe pertencem.
2 - Acoplamento e Repetição: Validações feitas no Controller não são reaproveitáveis por outros pontos de entrada (como jobs batch ou consumidores de mensageria).
3 - Dificuldade em Testes de Unidade: Testar a lógica de negócio exige subir o contexto do Spring MVC ou mockar objetos de requisição desnecessariamente.

Melhores Práticas e Alternativas

1. Bean Validation (JSR 380)
A forma mais elegante de lidar com validações de entrada no Spring é através das annotations do hibernate-validator. Isso mantém o código limpo e declarativo.

Annotations comuns: @NotBlank, @NotNull, @Size, @Min, @Email.

2. Validação Customizada
Para regras que dependem de condições específicas, prefira criar Validators customizados ou utilizar a camada de Service.

Exemplo Prático
❌ Abordagem Incorreta (Anti-pattern)
Neste cenário, o Controller está "poluído" com verificações manuais de estado.
@GetMapping("/{id}") public ResponseEntity<?> get(@PathVariable String id) { if (id == null || id.isBlank()) { return ResponseEntity.badRequest().body("ID inválido"); } return ResponseEntity.ok(service.findById(id)); }

✅ Abordagem Recomendada
Utilizando as facilidades do ecossistema Spring para manter o método enxuto e focado.

@GetMapping("/{id}") public ResponseEntity<?> get(@PathVariable @NotBlank(message = "O ID é obrigatório") String id) { return ResponseEntity.ok(service.findById(id)); }

Nota: Para que as annotations funcionem em parâmetros de @PathVariable ou @RequestParam, lembre-se de adicionar a anotação @Validated no nível da classe Controller.

Conclusão
Tratar o Controller como uma camada de passagem e delegar as validações para os locais corretos (DTOs com Bean Validation ou Service Layer para regras complexas) resulta em um código: