Luciano, Cogitamos esta possibilidade!!! Um middleware (seria este o nome?) que gerenciaria toda a regra de negócios e falaria diretamente com o banco de dados, vimos muitas vantagens mas para o modelo como estamos querendo não seria a melhor escolha.
Em 29 de junho de 2011 17:48, Luciano Schardosim <[email protected]>escreveu: > Senhores(as), > > essa discussão de onde deixar as regras de negócio muda muito. Mas uma > sugestões, se me permite, é trabalhar em camadas. Ou seja, aplicação, API de > dados, e banco de dados. Ou seja, use uma camada de abstração, dessa forma, > não importa a linguagem que você usa e não importa o SGBD que você usa. as > regras de negócio ficam na API. Stored Procedures são muito boas, mas tem > que ponderar uso destas pois o processamento das regras de negócio passam > para o SGBD e isso pode trazer maior lentidão nas transações, dependendo do > volume. Essa foi a solução adotada onde trabalho e tem dado certo. > > Espero ter contribuido. > > Abraços... > > > > Em 28 de junho de 2011 17:55, Roberto Mello <[email protected]>escreveu: > >> 2011/6/28 Udlei Nattis <[email protected]> >> >>> Neste caso o que queremos é permitir que a ferramenta seja feita em >>> qualquer linguagem, não apenas a que vamos desenvolver inicialmente. >>> >> >> Não seria uma otimização precoce? >> >> Como o Euler, eu também deixaria apenas as regras complexas para funções. >> O resto eu documentaria bem, de antemão, para criar uma API "modelo" que >> poderia ser mais facilmente portada para uma outra linguagem, e claro, com >> excelentes testes, tanto unitários como outros tipos. >> >> O mais difícil é conseguir iniciar com TDD (test-driver development). >> Depois o esforço extra se paga em pouco tempo. >> >> Também não estamos preocupados em esconder nada, inclusive é discutido na >>> empresa em montar o sistema em código aberto. Preferimos investir mais neste >>> hardware para garantir que transacoes, controle de estoque e geracao de >>> produtos sejam seguras do que deixar na mão dos programadores que geralmente >>> não entendem toda a complexidade do negócio. >>> >> >> Certo. Mas não esqueça que é mais difícil notar ineficiências/otimizar >> quando o SQL está enterrado dentro de funções. >> >> >>> Sabe me dizer onde encontro alguma documentação sobre? >>> >> >> Sobre o que? >> >> Roberto >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > ________________________ > Prof Luciano Schardosim > Mobile 51 9603.2608 > Email [email protected] > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Att. Udlei Nattis ---------------------------- Nixus Soluções Lojas Virtuais www.nixus.com.br
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
