none
Melhores Práticas RRS feed

  • Pergunta

  • Estou desenvolvendo uma aplicação em 3 camadas DOT NET.

    Minha dúvida em relação ao banco de dados SQL Server são:

    Eu sempre utilizo procedures quando preciso constantemente executar e sempre quando há necessidade de enviar/receber dados.

    Agora a questão é, utilizo todo o tipo de consulta, mesmo simples e pequenas em procedures ou views, ou utilizo no código dentro de uma camada, qual seria a melhor prática e recomendada?


    Carlos Lima
    quinta-feira, 26 de novembro de 2009 12:22

Todas as Respostas

  • Carlos,

    acredito que no conceito de 3 camadas todo scripts referente a banco deveriam ficar no banco em proc, view etc..

    mesmo pq se vc precisar fazer uma alteracao neste pequenos scripts vc nao precisa fazer um build da aplicacao e fazer deploy em cada maquina, basta alterar a proc e pronto todos estao atualizados...

    att.
    Marcelo Fernandes
    MCP, MCDBA, MCSA, MCTS. Se útil, classifique!!!
    quinta-feira, 26 de novembro de 2009 12:30
  • Carlos,

    Eu algumas aplicação 3 camadas que desenvolvemos aqui na empresa, trabalhamos desta forma, deixamos todas as regras de negócios na camada de banco de dados e qualquer alteração necessário realizamos no banco ao invês de fazer um novo build na aplicação.
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    quinta-feira, 26 de novembro de 2009 17:22
  • Olá Carlos,

    Acho que esse assunto "dá muito pano pra manga". Para pequenas e médias aplicações, eu até concordo que colocar tudo em SPs, Views, UDFs, etc mas quando o universo da aplicação sai do médio pro grande, essa regra pode ser muito boa ou se mostrar uma verdadeira armadilha.

    Se tudo está no banco de dados e você precisa crescer o que fazer ? Comprar um servidor de banco de dados mais poderoso, pois, o outro não aguenta. Quando você precisar crescer de novo o que será necessário ? Comprar mais um servidor parrudo de banco de dados e deixar o anterior de lado.

    Se a lógica não estivesse no banco, mas sim na aplicação, talvez as coisas fossem mais fáceis. Escalar um servidor Web ou um servidor de aplicação é muito mais fácil. Basta colocar uma máquina do lado e dividir a carga (Cluster LB, Webfarm, Webgarden, etc). Ao colocar a lógica no banco de dados, você está "matando" muitas dessas possibilidades.

    Outro ponto é que por mais desenvolvidos que os bancos de dados sejam, os servidores de aplicação possuem funcionalidades de DEBUG e log de erros muito mais evoluídas, o que torna encontrar o erro e tratá-lo mais fácil do que um banco de dados.

    Enfim, não estou dizendo qual é a certa ou qual é a errada, mas não se feche em um modelo conceitualmente inflexível. Avalie cada caso.

    Eu trabalho em um lugar que teve a cultura de no passado colocar tudo no banco de dados (desde INSERTs, lógicas de negócio até envio de e-mails). Fomos felizes por algum tempo, pois utilizamos recursos nativos, evitamos a troca de contexto entre a aplicação e a rede, reduzimos o tráfego de rede, etc, mas hoje tudo o que acontece é com o DBA. É extremamente complicado avaliar se o problema é de uma tabela fragmentada, de um INSERT lento, ou simplesmente de lógica de negócio. Só o que temos que tratar é o banco de dados "que está lento" sabe-se lá porque. O que nós podemos fazer se uma determinada SP tem que montar um relatório Cross Tab e isso envolve vários cursores ?

    A nova proposta de arquitetura irá tirar tudo do banco de dados. Não sei se é o melhor caminho, mas ficarei feliz de ver o outro lado da moeda. O que penso é que SPs, Procedures, Views devem sim ser utilizadas, mas somente para acesso à dados. Lógica de negócio na aplicação. No banco só casos raros e excepcionais.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com

    A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!814.entry
    Classifique as respostas. O seu feedback é imprescindível
    quinta-feira, 26 de novembro de 2009 21:45