Por muito tempo as stored procedures foram consideradas ótimas soluções para desenvolver as regras de negócio de uma aplicação, porém atualmente, com a grande diversidade de tecnologias, existe a grande dúvida se elas continuam sendo a melhor escolha. Recentemente passei por uma situação destas, na qual os sistemas Java precisariam interagir com regras de negócios que estavam dentro de stored procedures, e aí, será que vale a pena reescrever o código para Classes Java (EJBs)?
Vou compartilhar um pouco da experiência que adquiri tentando compreender um pouco mais as vantagens e as desvantagens de cada uma destas opções.
Na maioria das vezes, quando uma aplicação está lenta, a solução mais “fácil” é o upgrade do servidor. Porém, “não adianta colocar uma Ferrari se o motorista é o Rubinho” (Longhi, Fulvio). Algumas vezes a solução pode ser rever as soluções tecnológicas que estamos usando. Até porque Ferrari é um excelente carro, todos sabem, mas será que você conseguiria dirigir uma da mesma forma que dirige seu carro?
Fica mais fácil quando entendemos que não é porque uma tecnologia é mais nova que ela será melhor do que uma tecnologia já existente. Já vi muitos programas utilizando Java 1.3 que eram ótimos, mas quando foram migrados para Java 1.5 tiveram que ser refatorados depois, pois não atendiam tanto quanto a versão antiga.
Vantagens em utilizar EJB:
- Portabilidade: EJBs são independentes do banco de dados que estiver sendo utilizado. A forma de recuperar o initial context pode ser diferente para cada banco de dados, porém o código SQL no XML é para ser rodado em várias bases de dados;
- Temos Atomicidade, pela utilização de session beans (ou tudo é executado com sucesso ou seu estado original é retomado – rollback);
- Temos aplicações mais escaláveis;
- Pode ser tudo desenvolvido na própria IDE em que está sendo desenvolvida a sua aplicação.
Vantagens em utilizar Stored Procedures:
- Melhor performance devido a menor quantidade de transito entre redes (menos camadas até o banco de dados);
- Podemos alterar tabelas no banco de dados sem necessidade de recompilar as classes Java e restartar o servidor;
- Pode ser compartilhado entre várias aplicações utilizando a mesma base de dados;
- Portabilidade parcial (mudar de SO por exemplo, de Windows para Linux).
Assim sendo, a decisão irá depender de algumas questões como:
- Qual a importância da aplicação?
- A aplicação será reconstruída, ou sofrerá constantes manutenções?
- A aplicação terá diversas bases de dados?
- Existe a possibilidade de o banco de dados ser alterado?
- Qual a expertise da equipe desenvolvedora?
Já ouvi argumentos de pessoas dizendo que Stored Procedures facilitam a duplicação de código, porém não vejo isto como uma exclusividade das Storeds. Na minha opinião, o mesmo problema pode acontecer com os EJBs se o desenvolvedor não for cauteloso.
Podemos ver que algumas decisões acabam não sendo técnicas, e sim estratégicas, nas quais as vantagens técnicas não são o mais importante.
Não existe também nenhum impedimento em utilizar um repositório misto, tendo regras de negócio em stored procedures e em EJBs, desde que exista uma organização deste repositório, ou um responsável para prover uma organização.
Referências:
De 0 a 10, o quanto você recomendaria este artigo para um amigo?