Hibernate Validator e a consistência dos dados

Em qualquer tipo de aplicação, receber dados sempre foi um problema. Não é possível prever o que se passa na cabeça do usuário ou a interpretação que ele faz da interface da aplicação. Dessa forma, não podemos garantir que o sistema receberá as entradas no formato que precisa. É comum usuários digitarem números ou caracteres especiais em campos que não estão preparados para receber esse tipo de entrada. Se falarmos de formatos mais específicos, como datas, por exemplo, esse problema fica ainda mais evidente.

Isso ocorre porque o usuário não tem ideia de que a interface que ele visualiza é apenas a “ponta do iceberg”. Existem outras camadas que darão todo tipo de tratamento aos dados que ele acaba de inserir.

Dessa forma, se não for feito o tratamento adequado por parte das camadas da aplicação – não apenas na camada de interface, mas em todas as camadas -, erros podem ocorrer, sejam exceções que interromperão a execução do sistema ou problemas de integridade ou corrupção dos dados.

Cada entrada de dados do usuário segue um propósito, ou seja, é informação que será armazenada e processada pelo software com o intuito de fornecer uma resposta ao usuário. Neste contexto, é natural que algumas regras sejam estabelecidas para moderar a interação entre o usuário e o sistema. É para garantir o cumprimento dessas regras que o conceito de validação aparece. Validar é determinar se os dados capturados pelo sistema cumprem as regras lógicas definidas para manter a sua consistência.

Também é preciso ressaltar que a consistência dos dados influencia diretamente a qualidade do software, interferindo na forma como o usuário interage com a aplicação. Por exemplo, a experiência de receber uma mensagem de erro do sistema ao deixar um campo em branco ou preenchê-lo incorretamente é bastante desagradável, podendo deixar o usuário confuso em relação à forma de utilizar o software.

Como um problema clássico do desenvolvimento de software – pode-se dizer até da interação homem/máquina -, a validação das entradas dos usuários já foi abordada de diversas formas. Podemos citar como exemplo o uso de “máscaras” em campos de dados, que limitam as opções de digitação. Exemplos simples de restrições podem ser datas em um formato específico, a obrigatoriedade de um campo, campos que só podem receber números, etc.

Para validar essas restrições, diversas abordagens podem ser utilizadas, como o uso exceções para impedir que dados inconsistentes ultrapassem determinadas camadas da aplicação ou o uso de JavaScript nos campos de um formulário na Web.

A principal distinção entre os exemplos citados anteriormente reside justamente na camada em que cada uma das validações ocorre. É muito comum definir validações na camada de visão, que tem mais contato com o usuário (consequentemente, sobre a qual o usuário tem mais controle), e dependendo da arquitetura sobre a qual o software funcione isso pode torná-lo vulnerável. Há casos de validações escritas em JavaScript, portanto executadas no navegador, que são simplesmente desabilitadas pelo usuário.

O framework Hibernate fornece uma alternativa interessante, chamada Validator, para a validação de dados em qualquer arquitetura (Web, Desktop, etc.). De acordo com o site do Hibernate (veja o endereço na seção Links), o Validator permite expressar as regras de maneira padronizada através do uso de anotações (vide BOX 1) que representem a restrições desejadas.

BOX 1. Anotações (Annotations)

Anotações são recursos para a declaração de metadados – dados que descrevem outros dados – úteis para localizar dependências, configurações ou para fazer verificações lógicas. Essas definições serão, então, interpretadas pelo compilador para realizar uma determinada tarefa.

Como o Validator expressa as regras e restrições da aplicação por meio de anotações que podem ser estendidas, a implementação das validações é transparente, ou seja, não está relacionada a uma camada específica da aplicação ou a qualquer padrão de projeto.

O Hibernate Validator parte da premissa estabelecida pelo DRY (Don’t Repeat Yourself, veja o BOX 2), para que as regras e respectivas verificações sejam escritas uma única vez e gerenciadas de maneira centralizada. Dessa forma, mesmo que a arquitetura adotada seja em múltiplas camadas, não será necessário duplicar as validações.

BOX 2. DRY (Don’t Repeat Yourself)

É um conceito de programação, descrito por Andy Hunt e Dave Thomas – ambos cofundadores do Manifesto Ágil –, no livro “The Pragmatic Programmer”, que estabelece como meta a redução das repetições de informação de todo e qualquer tipo, especialmente entre as camadas da aplicação. De acordo com esse princípio, na medida em que cada elemento de negócio ou conhecimento do software é implementado univocamente, a modificação de um elemento não acarreta a necessidade de modificar outros." [...] continue lendo...