Lookup Personalizado - Artigo Revista Clube Delphi 131

Em RAD (Rapid Application Development), o tipo de projeto mais comumente desenvolvido em Delphi, VB ou C#, é muito comum o uso de lookups. Uma característica da programação RAD é que, da maneira como tradicionalmente os programadores fazem, ela é bem “procedural” e orientada a eventos. Além disso o foco, ou a direção do desenvolvimento é altamente dependente e inspirada em tabelas. Nesse ambiente, sempre que é necessário cadastrar um registro em uma tabela, por exemplo produtos, e necessita-se de uma chave primária de outra tabela, por exemplo família ou gênero, o programador tem três opções:

• Colocar um lookup para abrir a tabela a ser relacionada, mostrar os registros e trazer a chave primária do registro selecionado no registro que está sendo editado;

• Abrir um formulário de consulta, geralmente “inteligente” que fará perguntas para o usuário preencher campos e com isso montar em tempo de execução uma consulta que traga o mínimo de dados possível do banco, sendo assim bem mais performático;

• Subentender que o usuário já conhece de cor o código da família ou gênero e deixar que ele preencha manualmente, ou consulte primeiro depois preencha, fatalmente incorrendo em erro humano e em violação de integridade referencial caso essa regra não tenha sido imposta no próprio banco.

Por incrível que pareça existem grandes empresas, com ERPs grandes, conceituados e caros que usam a abordagem 3.

Não é intenção do artigo condenar o uso dos lookups tradicionais. Eles têm o seu lugar:

• Protótipos de programas, apresentações para clientes;

• Bases de dados com pouquíssimos valores, e valores fixos, como estados e ICMS;

• Programas em início de desenvolvimento;

• Programadores em início de carreira.

Os três grandes defeitos do lookup, não se restringindo apenas a esses três, são os seguintes:

• Só funcionam com seu dataset aberto, perdendo seus dados quando este está fechado;

• Com um número muito grande de registros eles ficam com uma superfície de seleção (a janela ou aba que se abre clicando-se na seta) muito grande, dificultando a vida do usuário;

• Geralmente não é possível impor filtros nos dados que preenchem o lookup, apenas definir quais colunas serão trazidas. As “linhas”, ou registros da tabela, vêm todas;

Nota: Como os lookups geralmente necessitam de duas colunas, a chave primária e outra que seja humanamente possível de se identificar um registro, não há necessidade de se popular os datasets dos lookups com “select * from tabela”, e este é uma das piores práticas de todas no desenvolvimento de sistemas, e é um dos principais motivos de lentidão, visto que todos os campos são trazidos.

Esses três problemas fazem com que o lookup se torne inconveniente e lento. A lentidão passa a ser cada vez mais perceptível com o crescimento do tamanho das tabelas no banco de dados. Se tornando pior ainda quando o servidor de banco de dados está em um servidor numa rede local e o cliente em outro computador desta mesma rede. Pior ainda se o banco de dados estiver hospedado em um serviço de hosting qualquer, o uso de lookups neste caso é impraticável.

Com certeza há saídas para este problema. Uma delas é usar clientdatasets como uma espécie de cache, que serão populados na inicialização do sistema e não mais se conectarão ao banco de dados. É a prática mais comum. Outra abordagem é colocar ComboBoxes comuns, não-lookups ou não-data-awares, e popular essas caixas de listagem com os valores na inicialização do sistema. Ambas as práticas podem tornar o sistema lento na inicialização.

Outro problema de carregar os dados na inicialização é que caso novos registros sejam adicionados a essas tabelas por outros usuários, em outras estações, os dados não serão atualizados nesses datasets que já estão abertos e populados servindo de cache. Seria necessário implementar um botão de “refresh” ou fechar e abrir novamente o sistema. Nenhuma das duas opções parece cômoda para o usuário. 

O meio termo é criar um formulário genérico de consulta que possa ser configurado para consultar qualquer tabela, trazendo os resultados da consulta em uma lista ou grid e devolvendo ao seu “chamador” o código da chave primária do registro selecionado. Esta é a técnica que muitos programadores usam. Mas cada vez que o formulário é chamado a consulta é refeita.

O ideal seria manter um cache de acordo com o que foi buscado, e refazer a consulta no banco de dados apenas se a busca for diferente. Essa regra impõe outra: o usuário deve digitar um mínimo de caracteres (um pedaço do nome, CPF ou família de produtos) para que a consulta seja feita e possa funcionar como um “autocompletar”. 

Para tirar pleno proveito da vantagem do RAD não seria conveniente ter que instanciar e destruir esse formulário de consulta (fazendo ainda as devidas conexões) toda vez que for necessário obter um valor de uma tabela mestre para popular uma chave estrangeira. Por isso o inteiro formulário de consulta pode ser encapsulado dentro de um componente. Se esse componente for um Edit com um botão já dispensa a tarefa de adicionar um Edit e um botão de consulta (ou um lookup) para cada campo em um formulário que seja uma chave estrangeira.