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

02/07/2008

1

Gostaria de um esclarecimento pois já vi algums artigos na internet onde sempre dizem para não usar o CommandText mais nunca explicam detalhadamente o motivo de não usar o CommandText, eu gostaria de saber o porque de não usar ele para sistemas 3 camadas, qual o problema ??? é mais lento, dá queda na performace,
ou só pelo falto de deixar a programação concentrada no servidor de aplicação e não no cliente ???

mais afinal de contas qual o real motivo ???

vejam esse topico
[url]http://singularsistemas.com.br/blog/2008/05/queries-dinamicas-no-servidor-datasnap/[/url]

Grato a todos..


Responder

Posts

03/07/2008

Brunolspp

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


Responder

03/07/2008

Luciano_f

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


Isso eu já imaginava.


Agora eu não entendi isso ::::
Mas acima de tudo...lugar de sql é no servidor


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

Select Campo01, Campo02, Campo03 From Tabela


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.


Responder

03/07/2008

Luiz Henrique

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+


Responder
×
+1 DevUP
Acesso diário, +1 DevUP
Parabéns, você está investindo na sua carreira