Atenção: por essa edição ser muito antiga não há arquivo PDF para download. Os artigos dessa edição estão disponíveis somente através do formato HTML.
Usando o objeto TClientDataset
Diga adeus ao CachedUpdates!
TClientDataSet é o personagem central da tecnologia de acesso a dados chamada MIDAS (Multi-Tier Distributed Application Services). Sua utilização, no entanto não está diretamente ligada a implementação por completo de uma aplicação multicamadas. É importante observar que uma aplicação usando TClientDataset é fundamentalmente uma solução Client/Server e, por esse motivo, tem uma série de implicações que precisam ser observadas, muito mais conceitualmente do que “programaticamente”.
A principal justificativa para utilizar o TClientDataset em nossos projetos é poder desfrutar dos benefícios de uma tecnologia altamente sofisticada, que substitui com grandes vantagens o uso de CachedUpdates, em todas as situações.
Vamos ver de uma forma simples e rápida de compreender o funcionamento dos componentes TClientDataset e TDataSetProvider, que são o cerne da nova tecnologia. Neste primeiro artigo tratamos como os dois componentes podem ser usados em um mesmo projeto sem que a base remota seja implementada – e aqui cabe uma observação importante, necessitamos de uma licença MIDAS quando usamos TDataSetProvider e TClientDataSet para transmitir dados de uma máquina para outra, caso contrário - ($$$$). Para maiores detalhes, consulte o arquivo LICENSE.TXT no diretório onde foi instalado o Delphi sobre ADDITIONAL LICENSE TERMS FOR DEPLOYNG MILTI-TIER PROGRAMS.
CLIENT/SERVER
A abordagem Cliente Servidor é diferente de uma abordagem Desktop, isso é óbvio, não precisava eu aqui escrever isso. O que por diversas vezes não fica claro é o quanto diferentes são esses dois mundos, o mundo TTable e o mundo TQuery.
O componente TTable já foi utilizado centenas de vezes por nós, o que devemos entender é por que o TTable em alguns momentos, o TQuery em outros. É extremamente comum nos grupos de “news” a pergunta: “O que é melhor usar: TTable ou TQuery?” O componente TClientDataSet pode receber dados de uma TTable ou de uma TQuery de forma não distinta, justamente porque ele não “vê” de onde os dados estão vindo, ele apenas se conecta a um TDataSetProvider e recebe os dados. Embora a coisa seja tão fácil quanto parece não é aconselhável que utilizemos uma TTable para esta finalidade, pois ela não está preparada para uma solução Client/Server que possa exigir uma criteriosa solicitação de dados.
Quando programamos utilizando o estilo "clássico", assumimos que os dados que estão sempre a nossa disposição, a qualquer momento, na forma e quantidade que desejarmos. Na prática isso não é bem verdade, existem diversos fatores que afetam a forma como esses dados chegam até o usuário de seu sistema em uma estação de trabalho, fatores que normalmente são ignorados.
Cliente Servidor quer dizer o seguinte: de um lado temos uma estação, onde o seu programa vai estar "rodando". Esta ponta é chamada de "CLIENTE". Por que cliente? Porque a estação vai estar solicitando dados ao servidor, então ela tem um comportamento característico de um cliente.
Na outra ponta está o "SERVIDOR" de dados, ele deve processar o pedido recebido da estação e enviar os dados necessários para a ponta solicitante.
Ótimo, isso é bem simples, mas por que então esse tipo e abordagem é tão diferente do nosso cotidiano?
Bom, imagine que temos um servidor de dados em Brasília e a sua estação de trabalho está em São Paulo. Quando uma tabela é aberta através do TTable é como se uma solicitação fosse enviada para o servidor pedindo a "tabela inteira", entupindo, literalmente, a rede e comunicação entre a estação e o server. Podemos até ignorar esse aspecto em redes menores ou em casos em que o volume de dados não é tão grande. Em reais aplicações client-server esse aspecto é o mais importante e foi devido a isso que a tecnologia foi desenvolvida.
Ou seja, o real objetivo do uso do ClientDataSet é minimizar o tráfego desnecessário entre a origem dos dados e local onde serão utilizados, manipulando, a cada momento, o mínimo possível de informação para concluir a tarefa desejada, viabilizando assim a existência de bancos de dados distribuídos e que estejam muito distantes do usuário final.
O CAMINHO A SER PERCORRIDO
...
