Desenvolvimento - Delphi

Delphi: Programação Cliente/Servidor - parte 1

A programação Cliente/Servidor envolve vários conceitos, os quais, partem da escolha do banco de dados a ser acessado, o qual, obrigatoriamente, deve ser um SGBD (Sistema Gerenciador de Banco de Dados...

por Flávio Lamberti



A programação Cliente/Servidor envolve vários conceitos, os quais, partem da escolha do banco de dados a ser acessado, o qual, obrigatoriamente, deve ser um SGBD (Sistema Gerenciador de Banco de Dados – Interbase, SQL Server, Oracle e outros). O simples fato de se utilizar um banco de dados Local (Access, Paradox, Dbase e outros) tira o título de Cliente/Servidor de um sistema.

O SGBD é imprescindível pelo simples fato do mesmo ter a capacidade de processamento do lado “Servidor”, isto é, todas as requisições de serviços feitas a este banco de dados serão processadas no servidor de banco de dados e não na estação que fez a requisição, que é o que acontece com os bancos de dados Locais, pois estes servem apenas para armazenamento de informações. Além desta vantagem os SGBDs tem outras características peculiares a eles, mas este não é o enfoque desta matéria, sendo assim, vamos adiante.

O esquema abaixo representa um acesso a um SGBD na maneira mais antiga, onde necessitamos de uma Middleware (camada intermediária de acesso – BDE, ODBC, etc...) para o acesso a este banco de dados. Mesmo sendo uma maneira antiga de acesso algumas empresas ainda mantém esta metodologia de trabalho por pura falta de tempo ou preguiça de converter os sistemas, pois a tecnologia que substituiria esta já se encontra disponível no mercado a bastante tempo.

Iremos analisar agora o que precisamos em nosso sistema para que tal esquema não perca suas características de Cliente/Servidor.

Para começar não podemos se quer pensar em utilizar um objeto TTable, já que o mesmo foi criado especificamente para acessos a bancos de dados Locais. Sua engenharia de acesso faz com que a Middleware seja a responsável pelo processamento das solicitações de serviços feitas ao servidor, não utilizando assim os recursos do servidor.

Então utilizaremos o objeto TQuery, este sim desenvolvido para acessos a SGBDs. O objeto TQuery possui uma propriedade chamada SQL na qual definimos uma instrução, em linguagem SQL, para acesso ao SGBD o qual tem a capacidade de interpretação desta linguagem, fazendo assim com que o sistema fique mais rápido em seu processamento e flexível em seu desenvolvimento.

Mas, este objeto retorna um pacote de dados Read-Only (somente para leitura), não suprindo então as necessidades de manipulação de dados (inclusão, alteração e exclusão), servindo somente para consultas. Isto não é bem verdade, pois um TQuery pode sim fazer manipulação de dados.

Nós temos a opção de habilitar a propriedade RequestLive do objeto o que não é recomendado, pois isto fará com que o objeto TQuery trabalhe como se fosse um TTable, isto é, ficando dependente da Middleware.

Partiremos então para segunda opção e que é a mais aconselhada. Já que o SGBD tem a capacidade de interpretação de instruções em linguagem SQL é ideal que se utilize deste benefício para uma melhor performance de nosso sistema. Para tanto precisaremos de um outro objeto do tipo TUpdateSQL. O nosso objeto TQuery deverá ser ligado a este objeto pela propriedade UpdateObject.

Após os dois estarem conectados devemos especificar as instruções de inclusão, alteração e exclusão em linguagem SQL dentro do objeto TUpdateSQL, através das propriedades DeleteSQL, InsertSQL e ModifySQL. Para os que não possuem conhecimentos de linguagem SQL para tanto e para aqueles preguiçosos assim como eu, temos ainda uma opção mais fácil para tal tarefa que se inicia por darmos um duplo-click no objeto TUpdateSQL que é quando se abrirá uma caixa de diálogo, nesta percebemos duas pastas : Options e SQL. Na pasta Options temos um combobox onde será exibido o nome da tabela a qual o objeto TQuery está acessando (isto é definido a partir da instrução SQL do TQuery ). Abaixo deste combobox temos alguns botões :

GetTableFields – o qual geralmente não é utilizado pois os campos da tabela são automaticamente relacionados;

DataSetDefaults – o qual desfaz todas as alterações realizadas nesta pasta;

SelectPrimaryKeys – o qual define o(s) campo(s) chave da tabela de acordo com as especificações da mesma no banco de dados e

GenerateSQL – o qual irá gerar automaticamente as instruções de Insert, Delete e Update em linguagem SQL, as quais aparecerão na pasta SQL.

Caso o programador queira e tenha o conhecimento necessário para tanto, ele pode alterar estas instruções, mas não é necessário, pois as mesmas funcionam como são geradas.

Na pasta Options ainda temos dois listboxs onde são exibidos, no da esquerda (KeyFields) o(s) campo(s) chave da tabela e no da direita (UpdateFields) os campos que terão seus valores alterados, incluídos e/ou excluídos pelas instruções em linguagem SQL.

Após estes procedimentos, que , no momento da leitura parecerão demorados, porém na prática são muito simples, o nosso TQuery está quase pronto para ser utilizado para manipulação de dados faltando apenas um passo mínimo mas de extrema importância, sem o qual não funcionará.

Basta agora habilitar a propriedade CachedUpdates do TQuery. Esta propriedade faz com que todas as alterações (inclusão, alteração ou exclusão) feitas nos dados sejam armazenadas na memória da máquina cliente (estação de trabalho), já que isto também faz parte do modelo Cliente/Servidor de desenvolvimento de sistemas. Isto mesmo, o acesso aos dados ou o envio das alterações realizadas nos mesmos para o banco de dados no modelo Cliente/Servidor não devem ser realizadas simultaneamente, isto é, o acesso ao banco de dados deve ser minimizado ao máximo. Os dados só devem ser enviados ao servidor quando os mesmos já estiverem totalmente prontos para tanto, devidamente alterados e condicionados pelas regras que regem o negócio do sistema, para evitar tráfego desnecessário de dados pela rede e processamentos que gerem erros de tratamento no SGBD, mantendo assim o servidor sempre disponível para os demais acessos.

Agora sim seu TQuery está funcionando a toda carga. Consultando, alterando, incuindo e excluindo dados.

E a maneira com que o código será gerado para isso? Será o mesmo código que você usaria com uma TTable: Append, Edit, Delete, Post, Cancel. A única diferença é que nós estamos trabalhando com os dados em memória e, em algum momento, estes dados deverão ser enviados ao servidor, para isso basta aplicar um método ApplyUpdates no objeto TQuery. O momento ideal para isto dependerá do seu negócio, geralmente isto é realizado após cada post ou delete.

OBS.: As manipulações dos dados serão feitas através do objeto TQuery, já que é ele o responsável pela persistência dos dados em memória. Então os métodos relacionados acima dizem respeito a este objeto e não ao TUpdateSQL.

É importante enfatizar que os conceitos Cliente/Servidor não param por aí, existe também a questão do controle de transações no banco de dados, realizado, neste caso, pelo objeto TDatabase, através dos métodos StartTransaction (início de transação), Commit (confirmação de transação) e Rollback (Cancelamento de transação). Uma transação deve ser iniciada sempre antes de se enviar os dados para o SGBD e a confirmação logo após este envio.

Quaisquer dúvidas sobre esta matéria estarei disponível para esclarecimentos através do email.

Flávio Lamberti

Flávio Lamberti