Uma ponto importante para quem desenvolve sistemas é o tráfego de rede. Espera-se que os sistemas de informações utilizem o mínimo possível os recursos da rede. Evitar acessos desnecessários ao servidor de aplicação e banco de dados é uma das providências que os desenvolvedores devem tomar pra diminuir esse tráfego.
Em sistemas web não seria diferente. Afinal o acesso a páginas web pode ocorrer via intranet, ou seja, na rede local, ou pela internet passando por vários servidores, bandas, nós, comutadores, etc. É importante evitar submissões de páginas desnecessárias. Isso pode fazer com que a navegação seja bem mais rápida e produtiva. Por exemplo, se for definido na aplicação uma regra que somentes CPF´s válidos podem ser gravados no banco de dados, a aplicação deve validar o CPF antes de gravar no banco. Mas onde essa validação deve acontecer? Algumas sugestões:
- Triggers na tabela – Antes do INSERT a trigger pode validar o CPF. O uso de trigger é desaconselhável, principalmente para validações de campo;
- Procedures - Se o sistema utilizar as procedures para implementar as regras de negócio, um ótimo lugar para validar o CPF é durante a execução da procedure;
Essa duas formas tem um problema em relação ao tráfego: os dados trafegaram a rede inteira apartir da tela do cliente até o banco de dados apenas para retornar “CPF inválido.”
Se utilizar um servidor de aplicação em uma arquitetura de n-camadas pode-se implementar a validação nos objetos de négocio. Isso já diminui um pouco o tráfego. Afinal o servidor de aplicação deve estar em uma camada acima, em relação a camada onde é feito o acesso ao banco de dados. O servidor de aplicação pode validar os dados e quando forem enviados à camada infeiror, os dados já foram validados na camada de regra de négocios.
Mas podemos subir camada ainda mais nessa validação. Podemos colocar a validação do CPF na camada de apresentação, exatamente no servidor web. Plataformas como PHP, ASP, ASP.NET, JSP podem utilizar essa forma. A página é submetida ao servidor web que faria a validação dos dados. Note que o servidor web deve ficar numa camada acima do servidor de aplicação. Agora o tráfego é apenas entre o cliente e o servidor web que já é muito bom.
Mas tem certas validações que podem ser feitas diretamente no cliente; lá no navegador. Vejamos alguns exemplos:
- campos que não podem ser nulos;
- data, cpf, cns, cnpj, etc. inválidos;
- comparação de dados entre dos campos.
Ou seja, se determinadas validações, também chamadas de pré-validações, forem checadas antes de submeter a página ao servidor web podemos evitar ao máximo tráfegos desnecessários em situações elementares. O campo CPF pode ser validado antes de o usuário enviar os dados ao servidor, ou seja, a página só seria enviada ou submetida ao servidor se o CPF fosse digitado corretamente, com os dois dígitos verificadores válidos. O mesmo podemos pensar com datas, horas e outros valores. Assim a diminuição do tráfego seria total. A gravação do CPF, ao ser validado no navegador do cliente, quando fosse enviado ao servidor certamente seria gravado já que o CPF sempre estaria correto ao chegar no servidor. Isso vale para vários outros tipos de campos: data, hora, data e hora, cnpj, cns, números, campos com dígitos verificadores, entre outros.
Essa validação no cliente pode ser feita com Javascript. Uma problema: “E se o navegador não suportar Javascript?” Realmente. Aí a validação deverá também ser feita em alguma das camadas inferiores citadas acima. Foi dito que essas validações seriam um tipo de pré-validações. Nenhuma aplicação deve ser feita apenas com validações no navegador do cliente. Algum outro local deve fazer a validação principal. Os objetos de negócio devem implementar as validações dos campos. Em programação orientada a objetos isso passa a ser um requisito técnico. Se a validação no navegador do cliente não funcionar, a verificação em outra camada inferior deverá ser feita.
O fato é que validar no navegador do cliente utilizando Javascript é um boa prática para qualquer sistema web. Em ASP.NET existe alguns componentes que realizam essa tafera com muita qualidade.
- RequiredFieldValidator: usado quando um campo não pode ser vazio;
- RangeValidator: usado para verificar se o conteúdo do campo está dentro de uma determinada faixa;
- RegularExpressionValidator: usado para validar campos utilizando expressões regulares;
- CompareValidator: usado para comparar dois campos;
- CustomValidator: usado para preparar uma verificação personalizada;
Todos esses validadores fazem verificações diretamente no navegador do cliente e só deixa os dados serem enviados ao servidor se os dados estiverem de acordo com as condições definidas nos validadores. Existe mais um componente chamado ValidatorSummary que é capaz de exibir mensagens de erro durante a validação. Leia mais sobre esses validadores neste link.
Gostaria de destacar a utilidade do CustomValidator. Ele permite utilizar validações personalizadas em Javascript. O desenvolvedor pode criar alguma validação de acordo com sua necessidade. Para utilizar este validador genérico a função em Javascript segue uma padronização na sua definição. O script para validação pode vir entre tags <scripts></scripts> na própria página ou em arquivos .js e vinculados a página. A função de validação pode ter qualquer nome sendo que os parâmetros de entrada devem ser source e arguments. Veja o exemplo:
<script language=”Javascript”>
function valida_vazio(source, arguments)
{
// O campo não pode ser vazio
if (arguments.Value!=”")
{
arguments.IsValid = true;
return true;
}
else
{
arguments.IsValid = false;
return false;
}
</script>
O exemplo acima faz a mesma coisa que o RequiredFieldValidator: valida campos que não podem ser vazio. O CustomValidator faz referência a esta função na propriedade ClientValidationFunction. Voce pode também combinar validators. Por exempo: O RequiredFieldValidator pode ser usado para verificar que um campo não pode ser vazio e o CustomValidator para verificar se o campo foi preenchido com um CPF válido por exemplo.
Note que essas validações no cliente apenas verificam a qualidade dos dados digitados. Elas não verificam, por exemplo, se o CPF está ou não cadastrado no banco. Esse tipo de validação tem que ser feita do lado do servidor.
Diversos tratamentos e validações pode ser feitos utilizando Javascript e o CustomValidator. Veja alguns exemplos:
- CEP
- CNPJ
- CNS
- CPF
- Data
- Data/Hora
- Números decimal
- Dígito verificador
- Email
- Hora
- Números
- PIS/PASEP
Essas validações são comumente utilizadas na maioria das aplicações. Eu implementei cada uma delas em Javascript e construi uma página em ASP.NET que demonstra a utilização de cada uma delas com o CustomValidator. Se desejar ver ou ter todas ou alguma dessas validações clique aqui.
Então é isso.
A segunda coisa é, caso este erro não tenha dado localmente, ou seja, tenha sido um erro gerado pelo usuário final, o sistema irá desviar o browser para a página de erro personalizada que criamos acima. Inclusive essa página pode ter um link para reiniciar o sistema. Se for um erro local, ou seja, na máquina do desenvolvedor, a página amarela com detalhes da exceção pode ser vista normalmente.
Comentários