Artigo Clube Delphi 94 - Usando todo o poder do TDataSetProvider

Sem dúvida nenhuma, um dos componentes mais poderosos da VCL é o DataSetProvider, que, além de prover dados a toda a aplicação, é capaz de auxiliar em uma série de funcionalidades no sistema.

Veremos o que há de mais interessante nesse componente e dicas avançadas para usufruir ao máximo de suas propriedades e métodos. Em conjunto com os componentes DBExpress o DataSetProvider é capaz de realizar inúmeras tarefas. Veremos nesse artigo:

·         Introdução ao DataSetProvider;

·         Como usar o UpdateMode e ProviderFlags;

·         Configurando dinamicamente o UpdateMode e ProviderFlags;

·         Uso de Constraints;

Criaremos diversos exemplos para entendermos corretamente cada funcionalidade do DataSetProvider;

Entendendo o DataSetProvider

Basicamente o DataSetProvider é responsável por enviar e receber os Data Packets da aplicação cliente para a o servidor de dados. Os Data Packets são os pacotes de dados trafegados na rede em uma aplicação duas camadas (“two-tier” ou “client/server”) ou “n” camadas (“n-tier”). Toda e qualquer requisição feita pela aplicação cliente é enviada ao DataSetProvider que por sua vez se encarrega de solicitar os dados ao servidor de aplicação. O result set, ou seja, o resultado da requisição é empacotado (“Data Packets”) e enviado de volta à aplicação cliente. Qualquer exceção levantada, seja na requisição ou no recebimento dos dados, é retornada a aplicação cliente.

Pode-se dizer que a utilização mais comum do DataSetProvider é feita em conjunto dos componentes da paleta DBExpress acrescido do componente ClientDataSet. Um exemplo de uso pode ser visto na Figura 1.

O que pouca gente sabe é que o DataSetProvider pode se tornar mais do que um simples componente de conexão com o banco de dados por ser farto de propriedades e eventos.

Figura 1. Exemplo de uso do componente DataSetProvider  

Constraints e DataSetProvider

Como sabemos, as constraints de uma aplicação podem ser inseridas de diversas formas em uma aplicação. Em aplicações two-tier, por exemplo, temos apenas dois lugares onde elas podem ser incluídas: no lado servidor ou na aplicação cliente. No servidor devemos inseri-las diretamente no SGBD através de Stored Procedures, domains, rules, triggers etc. É uma excelente idéia, pois centralizamos nossas regras de negócios em um único lugar. Porém, corremos o risco de ficarmos presos ao banco de dados que estamos trabalhando por conta da linguagem empregada no SGBD. Em outras palavras quando programamos diretamente no banco necessitamos usar a linguagem de programação SQL, também chamada ANSI, para criar nossas próprias instruções. Isso pode se tornar uma dor de cabeça em uma eventual mudança de banco de dados ou mesmo se o produto vier a ser comercializado com BD’s diferentes. Imagine um software que precisa ser capaz de se conectar aos bancos Interbase/Firebird, SQL Server 2005 Express e Oracle. De início já teremos algumas complicações entre Interbase e Firebird dependendo da versão de ambos, haja vista que muitas modificações no BD foram feitas ao longo dos anos. Por isso, da mesma forma que o esquema é interessante, também pode tornar-se um trauma.

Por outro lado é possível incluir constraints diretamente na aplicação cliente, porém temos uma enorme desvantagem: a decentralização de nossas regras de negócios. Elas precisam ser refeitas para cada nova aplicação e espalhadas por todo o código fonte ou em Units, componentes ou dll’s. Essa prática é altamente perigosa, pois podem ocorrer momentos em que uma regra de negócio pode não ser alterada por esquecimento dos membros da equipe de desenvolvimento, o que acarretaria em inconsistência dos dados.

Em aplicações n-tier (multi-camadas) podemos recorrer ao poderoso DataSnap e programar nossas regras de negócio diretamente no servidor de aplicação, tornando a aplicação mais consistente e inteligente. Essas regras residem no código fonte do servidor de aplicações, e ficam centralizadas.

Resumindo, uma das melhores alternativas certamente é fazer uso desta última opção, ou seja, utilizar um servidor de aplicação que fará o intercâmbio entre bando de dados (SGBD) e aplicação cliente, pois além de propiciar maior controle sobre as regras de negócios, ainda podemos disponibilizar a aplicação para acesso remoto através da internet.