Por que eu devo ler este artigo: Neste artigo mostraremos como funciona o processo de validação da JSR 349 – Bean Validation 1.1. Serão explicadas todas as anotações de verificação nativas da especificação e criaremos um pequeno sistema utilizando JSF 2.2 para demonstrar o funcionamento da biblioteca. A especificação Bean Validation permite a validação de atributos, propriedades, parâmetros e retornos de métodos, parâmetros de construtores, a criação de validadores customizados, o agrupamento de validações, entre outras funcionalidades. Tudo isto serve para evitar o armazenamento de dados inválidos no repositório de dados usado pelo sistema.

Validar os valores preenchidos em campos de entrada de dados é extremamente importante em aplicações. O procedimento evita que armazenemos sujeira em nossas bases de dados e, dependendo do caso, pode até mesmo ter impacto na segurança do sistema. Um dos mecanismos que podemos utilizar para realizar esta verificação surgiu com a liberação da plataforma Java EE 6, na qual foi introduzida a especificação Bean Validation 1.0. O objetivo principal da biblioteca foi auxiliar os programadores nesta tarefa, que muitas vezes toma bastante tempo durante o desenvolvimento.

Com o lançamento recente da plataforma Java EE, a JSR 349 foi liberada, introduzindo a versão 1.1 da biblioteca de validação. A atualização da especificação trouxe algumas novidades e entre as principais estão:

  • Uso de injeção de dependências e integração com CDI (ver BOX 1);
  • Validação de parâmetros e retornos de métodos;
  • Uso de grupos de conversão;
  • Suporte à concatenação de mensagens de violação através de expression language;
  • Integração com outras especificações, como JAX-RS (ver BOX 2).
BOX 1. Injeção de Dependência:

Trata-se de um design pattern que tem como objetivo abstrair de uma classe como um objeto do qual ela é dependente é instanciado. Na plataforma Java EE, o CDI é a especificação oficial que desempenha esta tarefa.

BOX 2. JAX-RS:

Produto oficial da plataforma Java EE que trata da criação de web services utilizando a arquitetura REST. Baseado em anotações, atualmente encontra-se na versão 2.0 e tem como implementação oficial o Jersey.

O processo de validação é todo baseado em anotações, porém, de forma alternativa, podem ser utilizados arquivos XML na configuração. A grande vantagem da especificação é que ela não está associada a um modelo de programação específico, podendo ser utilizada, por exemplo, em projetos web e desktop. A implementação oficial da especificação é o Hibernate Validator, que atualmente está na versão 5.0.1 e é fornecido pela Red Hat.

Neste artigo, veremos uma boa parte dos recursos dessa especificação, através da implementação de um pequeno sistema usandoJSF 2.2 e executado no servidor de aplicação GlassFish 4. Cada exemplo desenvolvido terá ilustrado o contexto em que se aplica e o código envolvido será detalhado para auxiliar na compreensão da API da JSR por parte do desenvolvedor.

O problema

Na maioria das aplicações web, a validação de campos ocorre em diversas camadas (da apresentação à persistência), pois os desenvolvedores têm o hábito de espalhar o código de verificação dos dados fornecidos pelo usuário em várias classes. Este tipo de abordagem traz uma série de problemas. Entre eles, podemos citar:

  • Presença de código duplicado por toda a aplicação;
  • Desperdício de tempo no desenvolvimento;
  • Aumento na probabilidade de ocorrência de erros;
  • Ausência de padronização no retorno dado ao usuário.

A Figura 1 mostra este tipo de cenário, em que o código de validação pode ser encontrado em várias camadas do sistema.

Java
Figura 1. Validação efetuada em várias camadas

A solução

A utilização da biblioteca Bean Validation no modelo de domínio da aplicação é, normalmente, a solução mais comum para esse tipo de cenário. Com ela, a validação do código pode acontecer de forma centralizada, pois nesta abordagem as anotações são comumente adicionadas apenas nas entidades, o que facilita o trabalho do desenvolvedor. A Figura 2 exibe esta configuração, em que todas as camadas podem invocar a verificação concentrada em um único ponto.

Domain Model
Figura 2. Validação centralizada no modelo de domínio. Fonte: Hibernate Validator Reference Guide

A especificação fornece uma série de validadores nativos que podem ser aplicados em nosso código (a Tabela 1 traz todos eles e uma descrição informando para que servem), entretanto cada implementação da JSR adiciona suas próprias anotações. A biblioteca Hibernate Validator, por exemplo, dispõe de anotações que verificam cartão de crédito, URL e, até mesmo, CNPJ e CPF, estendendo as opções para o programador.

Anotações nativas da especificação Bean Validation
Figura 2. Anotações nativas da especificação Bean Validation

Para explorar diversos recursos da biblioteca, criaremos um pequeno sistema que incluirá alguns exemplos úteis que podem ser adaptados para o cotidiano dos desenvolvedores. Como comentado anteriormente, o GlassFish 4 será nosso servidor de aplicação, que já traz embutido o Hibernate Validator, implementação oficial da especificação Bean Validation. Entre os recursos daJSR que iremos explorar neste artigo, estão:

  • Validação baseada em atributos;
  • Concatenação de mensagens de validação via expression language;
  • Validação baseada em propriedades;
  • Criação de um validador customizado;
  • Validação de parâmetros de métodos;
  • Validação do retorno de métodos;
  • Agrupamento de validações.

A aplicação carroweb

Para entendermos como funciona a validação através da especificação Bean Validation, criaremos uma pequena aplicação JSF 2.2 que simulará algumas operações envolvendo o cadastro de carros. Serão utilizados apenas validadores nativos da especificação, com exceção de um que iremos criar. O ambiente requerido para implementar o sistema envolverá os seguintes softwares, que precisam estar instalados na máquina do desenvolvedor (se necessário, confira a seção Links no final do artigo para saber onde baixá-los):

  • GlassFish 4;
  • Eclipse Kepler for Java EE Developers.

Além de instalar esses dois softwares, também é preciso configurar o GlassFish 4 entre os servidores disponíveis no Eclipse. Portanto, realize este procedimento primeiro, antes de começar a implementação dos exemplos. Na seção Links há um post do blog do autor em que é possível ver como realizar este passo.

Vale ressaltar que não seguiremos algumas das boas práticas de programação no desenvolvimento da aplicação – como reaproveitamento de código, utilização de templates do Facelets e escopo adequado para o Managed Bean a ser criado –, visto que o objetivo é apenas mostrar o funcionamento da JSR 349.

Criando a aplicação

Em primeiro lugar, precisamos configurar o projeto no Eclipse. Para isto, clique com o botão direito na view Project Explorer, selecione New e depois clique em Dynamic Web Project.

No campo Project Name, vamos informar o nome “carroweb”. Selecione como Target Runtime o GlassFish 4.0. Em Dynamic web module version, deixe 3.1 e na seção Configuration clique no botão Modify para alterarmos os recursos utilizados pela aplicação. Na tela que surge, marque o item JavaServer Faces e selecione a versão 2.2. Depois, clique no botão OK para confirmar e em Finish.

Vamos agora criar nossa primeira entidade. Para isto, expanda o nó Java Resources e clique com o botão direito em src. Feito isso, selecione New e clique no item Class. Na tela que surge, informe o package br.com.javamagazine.carroweb.model e em Name digite Carro.

Nosso próximo passo será criar os atributos que serão validados. Inicialmente serão oito e devem ser declarados como mostra o código da Listagem 1. Não deixe de inserir o get() e o set() ...

Quer ler esse conteúdo completo? Tenha acesso completo