Alguem exclareça porque não usar o CommandText em 3 Camadas

Fornece maior trabalho de manutenção, você perde a centralização das regras de acesso a dados e de negócio, dificulta a evolução e reutilização de código e abre oportunidade para SQL Injection.

Mas acima de tudo...lugar de sql é no servidor :D

Mais recursos do ClientDataSet e DataSnap vou estar apresentando no FDD 2008 dia 19/07

www.firebirddevelopersday.com.br

Isso eu já imaginava.


Agora eu não entendi isso ::::


até porque eu fiz monitoramente do comandos gerados e são todos SQL gerados no Servidor de Aplicação
o TClientDataSet apenas manda Instruções SQL pela rede o que é
muito Pequeno e tudo é feito no Servidor de Applicação
assim ele que vai gerenciar tudo a não ser que que se faça uma consulta do tipo



O retorno dessa consulta vai ser enviado do servidor para o cliente mais nesse caso mesmo sendo uma programação que não use comandText vai ter o mesmo resultado.

Boa Noite Luciano, tudo blz.

Eu não sou ai um expert e nem tao pouco ai um ´fera´ igual este ´rapaz´, o Bruno Lichot, ao qual devo a minha migração ao 3 camadas.
Nao se trata de somente ser assim ou assado e sim seguir a arquitetura 3 camadas. Voce deve ´mastiga-la´ para entender. Cliente -> Servidor ´Regras da´ Aplicacao -> Repositorio de dados. Sou um programador 2 camadas legitimo, e desde final 2007 estou fazendo estudos desta arquitetura, e posso te dizer que no NTIER, ´lugar de sql é no servidor´ ehehehehehehh. Usando sql no cliente, vai ficar assim Cliente->middleware->Banco de Dados, o que ai eu indico vc abandonar o 3 camadas e ficar no 2, pro teu sistema nao ficar um ´frankstein´.
Com isso nao estou dizendo que um e pior ou melhor. No inicio da tua ´migração de conceitos´, digo assim, porque programar EM e PARA 3 camadas é uma mudança de conceito. Fica tudo ´muito´ bem definido e você como programador deverá usar todo o teu conhecimento adquirido para escrever a aplicação dentro da arquitetura.
Tudo é questao de estar dentro do projeto, com isso, voce tem um resultado mais coerente e tudo mais o que o Bruno Lichot, o Daniel Maltarolli ratificam nos seus textos.
Este link por exemplo, que vc indicou ai, o Malta demonstra uma tecnica de criar um SQL no servidor usando ´inteligentemente´ metodos presentes no CDS(Cliente) -> DSP(Servidor), este configurando seu proprio DataSet.
Nao quero ser repetitivo, mas sito estas caracteristicas que chamam a atencao de um puro 3 camadas:
1) Centralização ´Real´ das regras de negocio na aplicacao servidora.
.Alterar um regra, sem necessidade de atualizar os Clientes.
2) Nao depender do banco ou de seus recursos, maior escalabilidade.
.Mudar de banco sem perder noites de sono. Nao que isso seja feito a toda hora e todo momento, mas so no fato de ficar todo o controle para a Aplicacao Servidor, sem dependencia real do banco, ja é uma dor de cabeça a menos.
3) Cliente magro(entre outras coisas, SEM SQL), possibilitando um controle de qualidade e transparencia infinitamente superior à Aplicação.
.Fora o uso PADRAO extensivo de ClientDataSetaSet, ja previamento integrado com a Aplicacao Servidora, chamadas a AppServer, enviando parametros e retornando resultados.
4) Balancear a aplicação em uso extremo.
...e etc, etc, etc....
Enfim Luciano, temos que aprofundar o conhecimento nesta arquitetura,
para entende-la melhor. Tambem nao adianta aqui ficar enumerando qualidades e caracteristicas da arquitetura se nao tivermos um conhecimento mais ´pratico´ para estas situaçoes.


Um abraço a todos ai, t+