Hibernate ou acesso direto via SP

“Comazzi”:

Com SP, eu elimino SQL dentro do codigo, ganho e performance. Se precisar trocar o banco de dados, so precisaria rescrever as stores procedures (o que eu nao acho um grande problema).

O que esta errado na minha linha de raciocinio ?

Vejamos, usando SP vc perde o recurso de ORM, ou seja, vai ter que trabalhar com JDBC diretamente, isso vai deixar teu código muito menos legivel e de pior qualidade. Teu dominio de negocio será muito mais fraco.

Em termos de performance, SP só tem ganho sensivel quando tem processo em lote envolvido ou voce coloca regra de negocio nela. Porém com hibernate voce ganha de forma facil acesso a lazy/eager loading e caching em 2 camadas, programar isso direito é muito complexo e melhora a performance bastante.

Quanto a “reescrever as SP não é problema”, bom, isso depende, se vc tem que portar do sqlserver por oracle em 1 semana e tem algo como 1500 SP para serem completamente reescritas tua opinião vai mudar radicalmente, sem falar que podem existir situações onde uma SP funciona muito rápido em um banco mas fica uma carroça reescrita para outro. Sem falar que o sistema TODO vai ter que ser testado novamente, isso não é uma tarefa simples.

Ou seja, Stored Procedures se e somente se voce tiver 101% de certeza que nunca vai mudar de banco de dados.

Primeiro: obrigado pela resposta.

Segundo: vc. nao fica com receio / medo de utilizar Hibernate em um projeto corporativo ? Digo isto pois o Hibernate nao eh o padrao ORM da Sun (mas pelo que li, o hibernate eh o padrao “de fato” adotado amplamente).

E se daqui a um ano o projeto fechar ou mudar radicalmente ? Existem muitas pressoes por parte de grandes empresas tais como ORACLE, IBM contra camada ORM tais como JDO, HIBERNATE etc.

Parece que até o JDO corre o risco de desaparecer (http://www.theserverside.com/news/thread.tss?thread_id=25695).

E ai, como fica o projeto ? Vale a pena correr este risco ?

“Comazzi”:

Primeiro: obrigado pela resposta.

Segundo: vc. nao fica com receio / medo de utilizar Hibernate em um projeto corporativo ? Digo isto pois o Hibernate nao eh o padrao ORM da Sun (mas pelo que li, o hibernate eh o padrao “de fato” adotado amplamente).

E se daqui a um ano o projeto fechar ou mudar radicalmente ? Existem muitas pressoes por parte de grandes empresas tais como ORACLE, IBM contra camada ORM tais como JDO, HIBERNATE etc.

Parece que até o JDO corre o risco de desaparecer (http://www.theserverside.com/news/thread.tss?thread_id=25695).

E ai, como fica o projeto ? Vale a pena correr este risco ?

Primeiro, ele não tem como fechar, por que é open source, se os desenvolvedores abandonarem a comunidade assume no lugar. Segundo que se ocorrer uma mudança drástica (algo como EJB 1.0 e EJB 2.0) vc pode se manter na versão antiga e apenas se aproveitar de patches para bugs;eu, por exemplo, estou usando o 2.0 pq a mudança para o 2.1 não se justificou dentro da empresa mesmo com a API sendo 100% compativel.

Um padrão adotado pela comunidade é muito mais forte que um desenvolvido pela industria, um exemplo disso é o struts. Alem disso, pega os frameworks semelhantes de todos esses vendedores juntos e a penetração não chega perto do 3 ou 4 colocado entre os OS.

JDO não vai desaparecer, isso é FUD. Pode ser que a especificação 2.0 não seja ratificada, mas já existem vendedores em vias de suportar…