Alessandro, quero deixar claro que quotar o post é perfeitamente normal. Você pode procurar nas mensagens que respondi e verá que diversas respostas minhas foram quotadas e continuie a discussão sem problemas. O Ponto aqui foii dizer que eu fui radical, sendo que logo após a minha frase sobre “inaceitável”, deixei claro que existem exceções sobre o assunto. Isso me deixou chateado sim.
Confesso que me excedi por causa disso e que poderia ter me expressado melhor. Portanto, minhas desculpas pelo que eu disse sobre você.
[quote=rjun][quote=peczenyj]
Qual o custo de dar manutenção nessas regras?[/quote]
Na verdade, isso nem foi levantado como hipótese já que o sistema não é nosso. Estamos apenas adquirindo. Levantei essa questão por que eu particulamente acho estranho deixar tudo, eu disse tudo, no banco de dados. O aplicativo (feito em não sei qual linguagem, mas suspeito que Delphi) serve apenas como uma interface de operação para o usuário. [/quote]
E foi exatamente em cima disso que eu fiz meu comentário no primeiro POST. Isso foi muito encorajado nas faculdades tempos atrás e tem muita gente ainda hoje que acredita ser a melhor forma.
[quote=marcosalex][quote=Emerson Macedo]
Isso foi muito encorajado nas faculdades tempos atrás e tem muita gente ainda hoje que acredita ser a melhor forma.[/quote]
Pois é. Será que é porque na tecnologia da época tinha vantagem isso?
A performance é bem superior, em muitos casos a codificação é menor e a manutenção é mais simples. Mas se o cara quiser fazer cagada e criar stored procedures salsichas, é terrível!
[/quote]
Antigamente, a programação de sistemas de informação era toda baseada nos dados. Portanto, como o banco de dados era a coisa mais importante, colocava-se o máximo de coisas possíveis e eram feitas aplicações com uma ferramenta de GUI qualquer, que apenas fosse apresentação para esses dados (Ou resultado do processamento destes). Ex: Delphi e VB. Você pode ver que o Delphi sempre foi cheio de controles ligando os campos da tela diretamente com o banco de dados, encorajando essa abordagem. Com a popularização da Orientação a Objetos, percebeu-se que desenvolver com objetos que tentem representar conceitos reais de negócio, ajuda muito na manutenção futura e no entendimento por parte de outros que leiam esse código. O nível de relacionamento entre código e os conceitos de negócio do software ficou bem melhor. Sem contar que frameworks de persistência ajudaram de tal forma que em algumas aplicações faz-se necessário apenas alguns ajustes no banco de dados, usando-o apenas para persistir o estado de objetos que estão numa memória volátil (RAM).
Quanto a manutenção mais facil quando o código está nas procedures, minha opinião é diferente. Acredito que nos objetos a manutenção seja mais fácil.
Acho este tópico muito polêmico para pouca coisa !
Tenho uma visão bem simplista sobre o assunto, banco de dados serve pra guardar dados e ponto.
Já trabalhei em mais de um sistema que tinha as regras de negocio no banco, na teoria é maravilhoso mesmo, mas acho que só quem trabalhou com isso pode dizer de situações pitorescas que acontecem, por exemplo:
Validar CPF/CNPJ, pô, ter que chamar o banco pra isso é besteira. (Você também tem opção de duplicar esta validação no cliente)
Reaproveitar código ! Isto na teoria é legal, mas nunca vi algum lugar que reaproveitasse lógica de maneira decente. Tudo fica muito dependente de tabelas e tipos de dados … coisas que com OO ficam muito mais simples de resolver.
Usar uma linguagem OO e ter regras no banco … os diferentes paradigmas não permitem ter um dominio de classes decente. No melhor dos casos, você consegue um modelo anêmico, ver detalhes aqui.
Se amarrar a banco de dados. Num dos sistemas que trabalhei a lógica estava no banco, um Sql Server, ao vender o produto para uma grande instituição, eles “bateram o pé” e só aceitavam se usasse Oracle … e ai ? O sistema teve que ser praticamente refeito em PL/SQL, sem contar que o lado “cliente” da aplicação também teve que ser bastante alterarado, ou seja, FAIL!
Comparado com as liguagens atuais, escalar banco de dados é um caos.
Resumindo, toda experiência que tive na área com aplicações com Regras de negócio no banco se resume a códigos que são obrigatoriamente remendados para usar termos/formas jurássicas de se programar em procedures.
Quem é obrigado a manter/desenvolver sistema já feito assim, tudo bem, faz parte, sinto pena de ti.
Agora começar um sistema do zero neste modelo, pra mim, é a maior roubada que alguém pode fazer.
Não sei se a melhor solução, mas sou a favor de modelar o dominio da aplicação numa linguagem de alto nivel (temos várias), se você não faz idéia de como, recomendo a leitura sobre Domain-Driven Design.
A implementação de DataBinding do Delphi não necessariamente encoraja a manutenção de regras de negócio no banco, até porque cada componente dispõe de dezenas de eventos para implementar essas regras na própria aplicação cliente. Na verdade, nesses cinco anos de programação em Delphi nunca vi nenhuma aplicação onde as regras de negócio estivessem totalmente no banco, boa parte dessas regras estavam mesmo na aplicação cliente.
Se vc aloca desenvolvedores num cliente, e no contrato diz que é esse cliente que vai ditar arquitetura, padroes e etc… vira pra ele e fala
que vc nao vai fazer regra de negocio no banco pq objetos é melhor.
Ele tira vc e poe quem faça. E vc perde alguns belos zeros na sua conta por radicalismo.
A implementação de DataBinding do Delphi não necessariamente encoraja a manutenção de regras de negócio no banco, até porque cada componente dispõe de dezenas de eventos para implementar essas regras na própria aplicação cliente. Na verdade, nesses cinco anos de programação em Delphi nunca vi nenhuma aplicação onde as regras de negócio estivessem totalmente no banco, boa parte dessas regras estavam mesmo na aplicação cliente.[/quote][/quote]
Bem, eu já vi muito.
[quote=fabiocsi]Se vc aloca desenvolvedores num cliente, e no contrato diz que é esse cliente que vai ditar arquitetura, padroes e etc… vira pra ele e fala
que vc nao vai fazer regra de negocio no banco pq objetos é melhor.
Ele tira vc e poe quem faça. E vc perde alguns belos zeros na sua conta por radicalismo. [/quote]
Por isso que eu evito trabalhar para empresas que tentam definir uma coisa que na verdade quem deve defirnir são Desenvolvedores/Arquitetos.
Bem, no caso dos EJBs eu sou. Não vi um sistema até hoje que tivesse a necessidade real de usar EJB. Nunca escutei de alguém um caso real em que EJB foi “a solução”. Sempre atrapalhou mais que ajudou. Mas em fim, sobre os EJBs basta dar uma procurada aqui mesmo no GUJ pra ver que eu não sou o único que diz isso. Na verdade acho que os demais já até se cansaram de ficar repetindo a mesma coisa por diversos tópicos.
Em todas elas você não viu nem 10% das regras no cliente? :shock:
Basta você ter um cálculo em um form ou em um datamodule… Voilá![/quote]
Vi sim. Isso era mais um problema. Regra em 2 lugares…
[quote=marcosalex] Passei por situações em que o código feito na procedure era 10% do código feito em Java e muito mais simples. Por isso julgo mais fácil a manutenção. Já vi situações de concorrência que tinha uma verdadeira ginástica em Java pra conseguir evitar incoerência do estoque de produtos com os estoques da loja. Foi substituído mais de 300 linhas de código por uma simples trigger de 5 linhas e funcionou com muito mais performance.
Bom, também já vi códigos que aconteceu exatamente o inverso, por isso não compensa generalizar. [/quote]
Joia. Seu exemplo foi legal, apesar de eu achar que o problema da “ginástica” pode ter sido falta de conhecimento pra fazer a coisa. Mas em fim, vamos aproveitar o gancho pra perguntar algumas coisas relevantes hoje em dia em relação a testes automatizados …
Como fazer testes automatizados em uma stored procedure?
Da pra fazer um mock das tabelas pra testar de forma unitária?
Carrega-se um banco vazio pra fazer testes?
Cria-se uma procedure pra testar a outra?
Essas questões são interessantes, pois desenvolver sem testes automatizados atualmente não é considerado uma boa coisa.
[quote=marcosalex][quote=Emerson Macedo]
Quanto a manutenção mais facil quando o código está nas procedures, minha opinião é diferente. Acredito que nos objetos a manutenção seja mais fácil.[/quote]
Passei por situações em que o código feito na procedure era 10% do código feito em Java e muito mais simples. Por isso julgo mais fácil a manutenção. Já vi situações de concorrência que tinha uma verdadeira ginástica em Java pra conseguir evitar incoerência do estoque de produtos com os estoques da loja. Foi substituído mais de 300 linhas de código por uma simples trigger de 5 linhas e funcionou com muito mais performance.
Bom, também já vi códigos que aconteceu exatamente o inverso, por isso não compensa generalizar.
Mas a maior desvantagem que vejo em deixar regras de negócio no banco é que não irão ficar todas as regras lá. Logo, você teria de dar manutenção em dois lugares, duas linguagens, duas plataformas,…[/quote]
Em suma, se quiser o melhor dos dois mundos, você terá que trabalhar (balanceadamente) com ambos.
Então nós concordamos que existe um problema relacionado a testabilidade para esse tipo de abordagem, certo?
Sim, mas de qualquer forma você tem que testar se a constraint que você criou está correta. A pergunta é: Como fazer isso? Você teria que manualmente rodar a procedure pra ver. Isso seria um trabalho manual e meio chato, o que é bem contrário ao objetivo dos testes automatizados.
É obvio que a Oracle vai dizer que por questão de performance o melhor é que a regra de negocio esteja no banco e a Microsoft tambem segue o mesmo caminho, tambem é obvio que isto deixa a empresa refem do banco e isto eles não dizem.
Para um sistema pequeno da para engolir esta idéia, isto porque se no dia amanhã a empresa resolver adotar outro banco não será muito dificel migrar todas as regras, agora pense em sistema gigante integrado que contenha todas as regras no banco, como será para migrar para outro banco ?. Como Diretor / Gerente de TI é fundamental levantar esta questão porque tudo é função do orçamento que esta disponivel para comprar (licenças), manter (DBAs) este banco ou migrar para outro banco.
Sob o aspecto comercial, software para venda, o ideal é que as regras estejam em um framework para que o cliente possa escolher em qual base irá investir, se é que não comprou ainda. Tive clientes que me disseram: “tenho um servidor linux e quero uma base OpenSource!”, neste caso minha salvação era que meu aplicativo não era dependente da base.
Os grandes ERP levam em consideração o lado do cliente e tambem deixa a base a criterio do cliente quando este já não possue uma.
Mais tem uma variante que é o contexto, já aconteceu no inicio da carreira quando sabia menos do que sei hoje(rsrsrs) não tinha conhecimento tecnico suficiente e muito menos tempo para estudar uma solução descente e ter que resolver muitas coisas direto no banco. Sei lá acho que chicotear um desenvolvedor por algo que não foi bem feito é complicado.