Neste artigo conheceremos um pouco mais sobre o componente SimpleDataSet do dbExpress, destacando seus recursos, cuidados com sua utilização, vantagens e desvantagens frente ao ClientDataSet. Agradeço aos vários leitores que enviaram e-mails sugerindo uma matéria sobre o assunto, em especial ao colega Márcio D. Marcondes, que gostaria também de saber por que o SQLClientDataSet foi descontinuado no Delphi 7. Antes de iniciarmos os estudos sobre o SimpleDataSet, para entendermos o porquê da sua existência.
Componentes dbExpress
Até o surgimento do dbExpress no Kylix 1 (e mais tarde no Delphi 6), o BDE (Borland DataBase Engine) era o principal mecanismo de acesso a dados no Delphi. O BDE não deve mais ser utilizado para novas aplicações, seu uso não é mais recomendado pela Borland, sendo recomendado a utilização do dbExpress para aplicações VCL.
Assim como muitos desenvolvedores, por vários anos utilizei o BDE, em especial para acesso ao DB2 e Oracle, até que surgisse o dbExpress. Apesar do dbExpress ter componentes semelhantes ao BDE, eles funcionam de forma bastante diferente. Por exemplo, você não usa um SQLQuery do dbExpress como usava um Query do BDE. O dbExpress foi cuidadosamente projeto para ser independente de arquitetura (2 ou 3 camadas). Cada componente no dbExpress tem uma tarefa distinta: você não pode usar um SQLQuery para conectar ao banco, fazer cache de dados, navegar, alterar dados e resolver as atualizações em cache. Você deve usar componentes diferentes para funções diferentes. No BDE, contrariando princípios básicos da OO, era possível usar um simples Query para realizar tudo isso - tarefa que no dbExpress envolve a utilização de no mínimo quatro componentes. Claro, no BDE é possível usar um DataBase para centralizar a conexão, mas isso não era obrigatório – e um UpdateSQL, caso queira utilizar Cache-Updates.
Usando dbExpress, você precisa normalmente de um SQLConnection, SQLQuery / SQLDataSet, DataSetProvider e um ClientDataSet.
Vale lembrar que o ClientDataSet e o DataSetProvider não pertencem exatamente ao dbExpress, mas são utilizados em conjunto com a tecnologia.
Como no dbExpress cada componente desempenha uma tarefa distinta, fica muito simples migrar uma aplicação do modelo 2 camadas para o modelo 3 camadas.
Uma discussão detalhada sobre dbExpress ou DataSnap está fora do escopo deste artigo. Sugiro que o leitor consulte a edição 46 da Revista ClubeDelphi. Lá mostramos como construir passo a passo uma aplicação 2 camadas usando dbExpress e depois facilmente migramos para 3 camadas. O que quero deixar claro aqui, é o motivo pelo qual o dbExpress utiliza vários componentes. Para quem está vindo do BDE, sugiro também dar uma olhada no comparativo dbExpress x BDE na edição 38.
SQLClientDataSet
Ok, é muito bom utilizar uma arquitetura como o dbExpress, que permite desenvolver de forma transparente para diferentes arquiteturas. Mas está longe de ser prático construir uma aplicação 2 camadas, visto a variedade de componentes que devem se utilizados, relacionados e configurados. Essa dificuldade fica ainda mais evidente para aqueles que vem do BDE.
Pensando nisso, a Borland criou o SQLClientDataSet no Delphi 6. Esse componente na verdade é o conjunto de 3 componentes.
O SQLClientDataSet é descendente de TCustomCachedDataSet, que descende de TCustomClientDataSet (classe base do ClientDataSet). Ele utiliza composição para usar recursos de um SQLDataSet e um DataSetProvider, que são criados internamente e não ficam “expostos”. Veja a seguir um fragmento do código fonte desse componente, retirado dos fontes da VCL:
TCustomCachedDataSet = class(TCustomClientDataSet)
private
FProvider: TDataSetProvider;
...
TSQLClientDataSet = class(TCustomCachedDataSet)
private
FDataSet: TSQLDataSet;
FSQLConnection: TSQLConnection;
...
Com isso, é muito simples criar uma aplicação sem que seja necessário configurar e relacionar uma variedade de componentes, visto que tudo é feito internamente pelo SQLClientDataSet. Essa abordagem, no entanto, tem algumas desvantagens:
- Uma migração para 3 camadas ficaria difícil, pois não há uma separação física entre os componentes;
- Não há maneira direta de acessar os recursos, propriedades e eventos dos componentes internos (SQLDataSet e DataSetProvider);
- Não é possível configurar os TFields do SQLDataSet interno;
- O componente foi descontinuado no Delphi 7;
Como o DataSetProvider e o ClientDataSet podem ser utilizados com outras tecnologias de acesso a dados (como BDE ou IBX), a Borland resolveu criar variantes do SQLClientDataSet, que ao invés de usarem dbExpress internamente, podem usar BDE ou IBX. Esses dois componentes, mais o SQLClientDataSet, são conhecidos no Delphi como “Cached DataSets”.
Instalando o SQLClientDataSet no Delphi 7
O SQLClientDataSet não vem mais no Delphi 7, mas é muito simples instalá-lo. Clique em File|New|Other>Package e salve o pacote como pkSQLClientDataSet.dpk em um diretório à sua escolha. No editor clique no botão Options, e na opção Directories/Conditionals digite $(Delphi)\Bin para a opção Output directory e $(Delphi)\Lib para as opções Unit output directory e DCP output directory. Volte ao editor, clique em Add e adicione ao pacote as units DBLocalS.pas e DBLRegS.pas que estão no diretório (Delphi)\Bin\Demos\DB\SQLClientDataSet. Finalize o processo clicando no botão Install.
SimpleDataSet
O SQLClientDataSet apresentou vários problemas no Delphi 6, tanto que, morreu por ali mesmo. No Delphi 7 ele foi descontinuado, dando lugar ao SimpleDataSet. Esse componente, que também é descendente de TCustomClientDataSet, é na verdade o conjunto de quatro componentes.
Veja a seguir um fragmento do código fonte desse componente, retirado dos fontes da VCL:
TInternalSQLDataSet = class(TCustomSQLDataSet)
...
TSimpleDataSet = class(TCustomClientDataSet)
private
FConnection: TSQLConnection;
FInternalConnection: TSQLConnection;
FDataSet: TInternalSQLDataSet;
FProvider: TDataSetProvider;
...
Ele possui algumas vantagens em relação ao SQLClientDataSet:
- Possui uma conexão interna;
- Permite acesso as propriedades e eventos do DataSet e SQLConnection internos;
- Permite configurar os TFields do DataSet interno;
O acesso aos TFields do DataSet interno é interessante nesse caso, pois permite configurar corretamente as ProviderFlags, que são utilizadas pelo DataSetProvider para determinar quais campos devem ser utilizados em instruções de Update e Delete.
O SimpleDataSet também tem desvantagens:
- Uma migração para 3 camadas também ficaria difícil, pelo mesmo motivo do SQLClientDataSet;
- O Componente não vem no Kylix, o que dificulta a criação de aplicações cross-platform; No entanto, se você tiver o Delphi 7, é possível recompilar o componente no Kylix a partir do código fonte da unit SimpleDS.pas.
Cuidados ao usar o SimpleDataSet
Quando você usa um Query do BDE, basta apontar a propriedade DataBaseName para um Alias, o que dispensa o uso de um DataBase. Internamente era instanciada uma conexão e compartilhada por todas as Queries que acessavam aquele Alias. Mas cuidado, no dbExpress isso é diferente: se você usar um SimpleDataSet e escolher um Connection.ConnectioName¸ cada SimpleDataSet terá sua conexão interna! E isso é errado! Você pode ter uma única aplicação consumindo dezenas de conexões com o servidor SQL.
Se você for usar mais de um SimpleDataSet, coloque um SQLConnection no DataModule e aponte a propriedade Connection dos SimpleDataSets para a conexão externa. Dessa forma, não serão criadas conexões internas.
Usar ou não usar o SimpleDataSet?
Pessoalmente aconselho que, sempre que possível, utilize os componentes separadamente. Apesar da configuração do acesso ser um pouco mais trabalhosa e cansativa, quando comparada ao Query / Table do BDE, essa abordagem é muitomais flexível e deixa você com total domínio da situação.
Configuração rápida
Mas ainda vamos precisar configurar vários componentes no DataModule para acessar uma simples tabela, e isso está longe de produtivo. Claro, esse é um preço que pagamos para ter uma maior flexibilidade e controle. Com a finalidade de dar produtividade ao desenvolvimento com dbExpress, desenvolvi um editor de componente para facilitar a vida de quem trabalha com dbExpress. Basta colocar um SQLQuery ou SQLDataSet, dar um clique de direita sobre ele e abrir o editor. Configure visualmente os parâmetros de acesso, e pronto, todos os componentes serão criados e relacionados automaticamente, incluindo SQLConnection, SQLDataSet / SQLQuery, DataSetProvider, ClientDataSet, DataSource e até mesmo controles Data-Aware (inclusive para IntraWeb). O editor possui ainda um Query Builder e possibilidade de exportação de dados para Word, Excel, HTML, XML e TXT.
Para aqueles que desejarem ver como o editor foi criado, ou mesmo se aprofundar no assunto sobre criação de editores de componente, consulte as edições 47 e 49 da Revista ClubeDelphi.
Use mais de um DataModule
ma última dica é com relação a organização dos componentes no DataModule, para aqueles que desejarem usar os componentes separadamente ao invés de utilizar SimpleDataSets. Para grande sistemas, aconselho a criação de DataModules por entidade. E mais, para quem usa dbExpress, aconselho criar um DataModule “servidor” (com os componentes dbExpress e DataSetProviders) e um “cliente”, com os ClientDataSets. Isso mesmo para uma aplicação duas camadas. Dessa forma, você não terá imensos DataModules com dezenas de componentes, e essa divisão tornará mais flexível o processo de migração para 2 camadas. Isso foi demonstrado na edição 46.
Um abraço à todos e até a proxima!
