DBX: Abordagem Otimizada
No uso de DBX, normalmente temos o conjunto TSQLDataset, TDatasetProvider e TClientDataset ou TSimpleDataset, encapsulando os três.
No entanto, usando os componentes separados, caso tenhamos [u:e418929852]poAllowCommandText = true[/u:e418929852], um SQLDataset e um DatasetProvider podem servir a vários ClientDatasets.
O benefício é a redução da quantidade de objetos (e configurações). E quando necessário, nada impede que determinado(s) ClientDataset(s) tenha(m) seu(s) SQLDataset e DatasetProvider específicos.
Em princípio, a confiabilidade proporcionada pelo Delphi sugere que esta arquitetura possa ser utilizada sem problemas. A preocupação é com ´efeitos colaterais´ que possam advir: gerenciamento de ponteiros, performance etc.
Gostaria da opinião de alguém que já tenha tido a experiência ou que se disponha a tê-la ou, ainda, que possua conhecimento teórico suficiente para aprovar ou desaprovar a idéia.
Henrique
No entanto, usando os componentes separados, caso tenhamos [u:e418929852]poAllowCommandText = true[/u:e418929852], um SQLDataset e um DatasetProvider podem servir a vários ClientDatasets.
O benefício é a redução da quantidade de objetos (e configurações). E quando necessário, nada impede que determinado(s) ClientDataset(s) tenha(m) seu(s) SQLDataset e DatasetProvider específicos.
Em princípio, a confiabilidade proporcionada pelo Delphi sugere que esta arquitetura possa ser utilizada sem problemas. A preocupação é com ´efeitos colaterais´ que possam advir: gerenciamento de ponteiros, performance etc.
Gostaria da opinião de alguém que já tenha tido a experiência ou que se disponha a tê-la ou, ainda, que possua conhecimento teórico suficiente para aprovar ou desaprovar a idéia.
Henrique
José Cordeiro
Curtidas 0
Respostas
Steve_narancic
01/08/2006
Não sabia que isso era possivel, mas posso ter dois clientdatasets abertos ao mesmo tempo nesta configuração, ou tenho que ter o cuidado de não permitir que dois clientdatasets sejam abertos ao mesmo tempo?
GOSTEI 0
Adriano Santos
01/08/2006
Não sabia que isso era possivel, mas posso ter dois clientdatasets abertos ao mesmo tempo nesta configuração, ou tenho que ter o cuidado de não permitir que dois clientdatasets sejam abertos ao mesmo tempo?
Você pode ter vários CDS´s ativos ao mesmo tempo, pois o CDS carrega e manipula os dados localmente. O cuidado principal é na hora de fazer o update ou post, pois estes dois empacotam os dados e os enviam ao DataSetProvider que por sua vez envia ao SqlDataSet e assim sucessivamente até que a operação seja finalizada. Qdo vc abre o CDS vc usa o comando SQL do SqlDataSet e seus parâmetros, desta forma se tiver algo como ´SELECT * FROM CLIENTES´ o resultado desta query será ´jogado´ para o CDS onde vc trabalhará localmente, por isso é mais rápido tb.
Agora, quanto ao poAllowCommandText = True, um colega nosso teve problemas recentemente aqui no fórum, a discussão parou no meio acho que sem solução.
[url=http://forum.clubedelphi.net/viewtopic.php?t=75542&highlight=poallowcommandtext]Tópico[/url]
GOSTEI 0
Dmalta
01/08/2006
Usar a opção [i:c72fc5f7b1]poCommandText[/i:c72fc5f7b1] é subverter todo o propósito de uma arquitetura 3-camadas. Por isso eu digo: poCommandText é o MAL! :)
Salvo se você estiver usando como uma aplicação tradicional cliente/servidor (2-camadas), não vejo sentido em usar SQL do lado cliente.
A vantagem do DataSnap é a abstração de dados na camada cliente. Você pode mudar livremente o método de acesso a dados, a lógica de programação e até o banco de dados.
Escrevi mês passado um post no meu blog sobre isso:
[url]http://dmalta.blogspot.com/2006/07/lugar-de-sql-no-servidor.html[/url].
Salvo se você estiver usando como uma aplicação tradicional cliente/servidor (2-camadas), não vejo sentido em usar SQL do lado cliente.
A vantagem do DataSnap é a abstração de dados na camada cliente. Você pode mudar livremente o método de acesso a dados, a lógica de programação e até o banco de dados.
Escrevi mês passado um post no meu blog sobre isso:
[url]http://dmalta.blogspot.com/2006/07/lugar-de-sql-no-servidor.html[/url].
GOSTEI 0
Adriano Santos
01/08/2006
Usar a opção [i:fabc3e2d66]poCommandText[/i:fabc3e2d66] é subverter todo o propósito de uma arquitetura 3-camadas. Por isso eu digo: poCommandText é o MAL! :)
Salvo se você estiver usando como uma aplicação tradicional cliente/servidor (2-camadas), não vejo sentido em usar SQL do lado cliente.
A vantagem do DataSnap é a abstração de dados na camada cliente. Você pode mudar livremente o método de acesso a dados, a lógica de programação e até o banco de dados.
Escrevi mês passado um post no meu blog sobre isso:
[url]http://dmalta.blogspot.com/2006/07/lugar-de-sql-no-servidor.html[/url].
Muito boa sua explanação sobre o assunto Daniel (li seu blog e comentei este mesmo comentário aqui). Na minha idéia de desenvolvedor penso da mesma forma. A única providência que tomo muito cuidado é quanto a programação no banco, [b:fabc3e2d66]storedproc[/b:fabc3e2d66] por exemplo eu não adoto devido ao fato de trabalhar com mais de um bd no meu software. As incompatibilidades de comandos sql me incomodam e prefiro fazer algo o mais genérico possível evitando crashs no programa devido a um ou outro comando sql que não existe no banco atual. É isso ai.
GOSTEI 0