Bom dia, entrei em uma discussão saudável com um DBA aqui da empresa, onde se deve deixar a regra de negocio de uma aplicação.
Eu como sou “novo” menos de 2 anos trabalhando com desenvolvimento, vejo uma vantagem deixar a regra de negocio na aplicação visando sempre a portabilidade, pois meu cliente pode a qualquer momento querer usar outro banco de dados e caso eu deixe a regra no banco de dados, estou “preso” aquela base e caso o cliente queira migrar de banco de dados terei muito mais trabalho para reaplicar as regras novamente no banco.
Porem o DBA defende isso e tem bons argumentos, como aumento do desempenho da aplicação, onde uma vez usando frameworks ORM a aplicação perde em desempenho.
Claramente devo visar a performance do meu sistema, mas estamos em um mundo onde nao podemos ficar preso, portabilidade e tambem mobilidade.
O que voces podem me disser? Isso agrega conforme a necessidade da empresa? Acha que não devo dar atenção a portabilidade e deixar a regra totalmente acoplada em uma base de dados?
A justificativa de que “o cliente pode mudar de banco de dados” é extremamente volátil. Dificilmente muda-se o banco de dados.
A justificativa de que “a performance é melhor”, também pode ser balela. Frameworks ORM nem sempre são o limitador (gargalo) de um sistema.
Usando um servidor de aplicação, eu acredito que enfiar as regras de negócio no banco é negar a existência do servidor de aplicação. O argumento de performance, pra mim, é muito falho pois o banco relacional é muito mais complicado de escalar do que o servidor de aplicação e, pensando um pouco mais orientado a objetos, as regras de negócio fazem parte do comportamento dos objetos do sistema. Separá-los é criar o famoso Modelo Anêmico.
Apesar de performance sempre ser uma preocupação, acho que outras preocupações acabam sendo um problema maior e teriam maior prioridade. Uma delas que posso citar é a facilidade de manutenção. O que você acha que é mais fácil manter, código java ou código PL/SQL (no caso do oracle)? Eu fico com Java.
[quote=drsmachado]A justificativa de que “o cliente pode mudar de banco de dados” é extremamente volátil. Dificilmente muda-se o banco de dados.
A justificativa de que “a performance é melhor”, também pode ser balela. Frameworks ORM nem sempre são o limitador (gargalo) de um sistema.[/quote]
Voce teria uma resposta mais plausível, pois eles(DBA) sempre caem sobre os ORM que tem perca de performance.
Gostei de sua resposta também penso dessa maneira, so nao sei muito sobre o “famoso Modelo Anêmico”.
[quote=douglascst90][quote=drsmachado]A justificativa de que “o cliente pode mudar de banco de dados” é extremamente volátil. Dificilmente muda-se o banco de dados.
A justificativa de que “a performance é melhor”, também pode ser balela. Frameworks ORM nem sempre são o limitador (gargalo) de um sistema.[/quote]
Voce teria uma resposta mais plausível, pois eles(DBA) sempre caem sobre os ORM que tem perca de performance.
Gostei de sua resposta também penso dessa maneira, so nao sei muito sobre o “famoso Modelo Anêmico”.[/quote]
O que um framework ORM faz é tirar o teu trabalho de criar queries na mão. Se você não souber criar queries, corre um grande risco de criar gargalos, com ou sem ORM.
Por outro lado, se o banco de dados não estiver adequado, nem mesmo SPs, functions ou o que seja serão bons, eles também serão lentos.
Dificuldade de manutenção futura, geralmente programador PL/SQL faz códigos gigantes num mesmo procedimento, está no DNA. Depois de anos ninguém consegue entender e fica aquele drama com uma tarefa só para decifrar toda a procedure.
Dificuldade de contratação, pois maioria dos desenvolvedores fogem disso e quem for obrigado a mexer vai meter o pé da empresa.
Se o ORM é problema (nunca tive problema pois uso de forma adequada, vide topico), então que não se use ORM ou use só onde não for critico.
Regras de Negócio na Aplicação, não tenho nenhuma dúvida.
1- maior facilidade na manutenção, debug
2- organização 1000x melhor.
3- muito mais coeso sem repetição de código.
4- você entende como funciona a lógica do negócio se for código java, se for codigo plsql, você precisará de documentação, tempo de casa antes de ler o código, simplesmente monstro.