Lugar de SQL é no servidor
Eu não sou muito rigoroso com relação a arquitetura 3-camadas desde que todo o SQL fique exclusivamente no servidor de aplicação e nada mais que a interface de usuário fique na camada cliente. :-)
Não faz nenhum sentido desenvolver um sistema multicamadas com código SQL no lado cliente - embora cada dia conheça mais desenvolvedores ou empresas que insistem em fazer exatamente isso. Ou há uma divisão de responsabilidades entre as camadas, ou simplesmente não existem camadas.
Uma servidor de aplicação com um único TDataSetProvider genérico não passa de um gateway para o banco de dados. É um middleware de conectividade, não de acesso a dados. O grande benefício do DataSnap é a abstração de acesso a dados que proporciona à aplicação cliente. Para mim, é a sua razão de existir.
Recentemente eu fiz uma alteração em uma aplicação que realiza milhares de vezes por dia uma consulta rápida dada a chave primária de uma tabela como parâmetro. Com o tempo essa consulta foi ficando mais e mais complexa, com diversos JOINs, e decidi transformar a query dinâmica em uma stored procedure. Apenas alterei o componente TADOQuery para um TADOStoredProc e conectei o TDataSetProvider diretamente a stored procedure. O formato dos parâmetros não foi alterado, portanto a aplicação cliente manteve-se intacta. Nem tomou conhecimento da alteração, só do ganho de performance.
Artigo publicado originalmente em 26/07/2006.
Comments
5 Responses to “Lugar de SQL é no servidor”
Deixe uma Resposta
-
-
Sobre
Malta on Delphi é um site de artigos técnicos originais sobre Delphi.
-
Blogroll
Muito boa sua explanação sobre o assunto Daniel. Na minha idéia de desenvolvedor penso da mesma forma. A única providência que tomo muito cuidado é quanto a programação no banco, storedproc 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.
[...] eu digo que lugar de SQL é no servidor é porque vejo muitos programadores Delphi usando DataSnap como um simples middleware de [...]
[...] SP não fere nenhum princípio de desenvolvimento multicamadas. De fato, o SQL fica no servidor, não no cliente. Tem gente que prefere não ter nenhuma lógica no banco de dados e tratá-lo como [...]
Boa tarde.
Gostei da sua matéria e concordo contigo.
No caso de Mestre/Detalhe como você resolveria sem ter Generator nem Procedure buscando a chave no lado do cliente?
Estou fazendo testes com Servidor de Aplicação e uma Aplicação Cliente, porém no momento do UpdateRecord no servidor estou encontrando dificuldade para passar corretamente a chave do mestre no detalhe.
Encontrei algumas matérias, onde é feito muita gambiarra (passar número negativo, ler o detalhe e regravar o código correto, etc…), não acredito que para trabalhar com Clientdataset em 3 camadas, utilize tanto POG assim.
Como faço para da aplicação cliente executar uma storeprocedure que esta na aplicação servidora(SOAP).