Pensando em um sistema grande, com varias regras de negocio.
Ate que ponto eh vantagem utilizar um ORM.
Em sistema de medio e grande porte, eh utilizado msm.
Jah trabalhei com Hibernate, eh extremamente produtivo, mas vc nunca tem 100% de controle sobre oq esta sendo feito, comparando com jdbc convencional.
Estou a um certo tempo meio q afastado da area java.
Caso eu venha a utilizar msm um ORM, consigo utilizar somente JPA sem depender do Hibernate, EclipseLink e afins ??
Construir classes POJO msm.
É sempre bom vc usar um ORM, msm pq vc ñ tem obrigação de usa-lo em 100% das suas regras de negócio, quando vc precisar se mais controle use JDBC. Quanto a dependência do provider, eu sempre tento desenvolver um código mais compatível com a especificação mas se for conveniente p/ vc usar algum recurso especifico do provider faça. Mas faça de modo q fique claro q aquele código especifico ñ é compatível com a especificação, assim ficará mais fácil localizar esse código caso vc resolva mudar de provider no futuro.
meu amigo em um sistema vc não precisa usar 100% ORM… ORM ele te ajuda muito mas muito mesmo… é realmente muito produtivo porem a casos principalmente em consultas complexas, relatórios que ele não é a melhor saída e isto não significa que por causa destas exceções vc não poderá usar orm… pois vc pode combinar ambos… orm e o jdbc convencional desde que claro isto esteja bem implementado pois senão vira bagunça…
ORM se sai bem em qualquer banco de dados.
Pode sim utilizar JPA 2 sem usar frameworks de persistência.
O hibernate tem muitas abilidades. Este cara consegue de maneira incrível deixar algumas coisas mais rápidas. É um cara q tem anos de experiência.
Mas com crtz cada caso é um caso e tem lugares q toda essa experteza não vale muito, ou até atrapalha. É aí q vc deve fazer na mão.
Lembrando q, o hibernate tem as querys nativas, mas para estes casos de nada adianta, sendo q ele vai continuar fazendo seus algorítimos para tentar agilizar as coisas.
Eh imagino msm que juntar o melhor dos dois mundos seja o mais interessante.
Afinal de contas ngm merece ter q fazer SQL de crud.
Utilizei hibernate com interface em flex, lembro q na epoca apanhamos muito com relacao ao lazy loading, q acabava trazendo “todo” o banco nas consultas mais complexas.
quando usei JPA, acabei usando hibernate tb por causa dos criteria, acho q foi soh.
Quanto as hailiddes do hibernate, ah q vc se refere.
Usando somente JPA, perderia muita coisa.
Penso no custo beneficio de ter q adotar um Hibernate da vida, e amanha ou depois, descontinuarem ou aparecer um bug q demorem a resolver e afins…
E aki na empresa nao decido sozinho tb, e o pessoal q desenvolve bastante com Delphi, fica relacionando tipo o hibernate com um componente Delphi fechado.
Cara, esse negócio de aparecer um bug e demorarem pra resolver é besteira. O hibernate chega a ser um padrão de mercado e não qualquer coisinha q possa ser descontinuado. É só pesquisar mais um pouco e verá q ele é o cara.
Quanto ao lazy loading com crtz não foi feito da melhor forma. O hibernate é bastante customizável e o correto com o lazy era justamente não trazer todo o banco.
O hibernate tbm é open source. Se vc quiser continuar ele vc pode. Nada no java é parecido com o delphi.
Se quer utilizar as melhores formas de se programar em java é isso aí, de resto pode virar uma gambiarra.
Dificilmente vc se encontrará em uma situação que utilize JDBC puro por questões de agilidade. Te digo isso pq já trabalhei em projeto grande, alta performance (www.teleton.org.br) (ahh… e não é só a telinha de doações não, tem todo um dashboard de consulta pro silvio santos e toda a galera lá, além de integração web service com os telefones 0500, 0800, entrega de brindes, controle de programação, predições de valores com base nos horários … vixiiii … muita coisaaaa . !!) =]]
Quando eu uso JPA (sempre! :)) eu procuro usa-la p/ tudo a menos q ela me cause alguma inconveniência tipo perda de performance ou quando eu percebo q alguma query ficaria mais simples se fosse escrita em SQL nativo. Na maior parte dos casos vc pode recorrer às NativeQueries do JPA, mas há algumas situações, principalmente aquelas em q vc precisa lidar com dados tabulados e ñ objetos, em q ResultSets são melhores q objetos. Tente nunca otimizar cedo demais, primeiro faça do modo mais simples e só parta p/ um código otimizado quando vc perceber q essa solução ñ é realmente boa, afinal, códigos simples são mais fáceis de manter.
Vc ñ deve perder muito em usar apenas JPA sem as features proprietárias do Hibernate, mas se vc estiver usando Hibernate como seu JPA provider vc sempre terá a opção de mudar quando vc achar q é conveniente.
Eu particularmente prefiro evitar o uso extensivo de APIs de criteria em favor das NamedQueries. API de criteria foi criada p/ casos onde vc precisa criar queries dinamicamente e ñ p/ os casos corriqueiros. NamedQueries são menos custosas em termos de quantidade de código e ainda podem substituir o clássico padrão DAO pq combinado com NamedQueries o EntityManager do JPA é um ótimo DAO genérico.
Quanto aos problemas com lazy loading, com um código correto vc pode lidar com ele facilmente, na maioria dos casos ao menos!
Antes, uma pergunta pro aluisiodsv, se me permite:
Qual o servidor de aplicações que vocês usaram para implantar o teleton?
Pergunto isso por que utilizo o Glassfish em produção e sempre tive curiosidade de saber quais os servidores j2ee mais utilizados em ambientes que exigem alta performance.
Sobre o assunto do tópico.
Concordo que o orm nos auxilia muito no desenvolvimento, a única coisa que fico com o pé atrás é com a qualidade das implementações dos provedores de persistência (no caso do jpa).
Hoje mesmo, por coincidência postei um problema aqui no guj com um problema que estou tendo com o que parece ser deadlock no acesso concorrente ao cache do toplink: http://www.guj.com.br/posts/list/221313.java
Isso pra não falar nos “remove()” que não apagam o registro no banco, registros duplicados, etc. que também já vi ocorrer.
Eu tentei usar o hibernate como provedor de persistência em outra aplicação que ainda está em desenvolvimento, mas pelo menos nos meus testes ele se mostrou bem mais lento que o toplink, embora eu reconheça que não cheguei a fazer um ajuste fino nas configurações do hibernate para tentar melhorar a performance.
O deadlock pode ser um bug, infelizmente nada nem mesmo os driver JDBC estão livres deles. Isso ñ significa q a implementação seja ruim.
Quanto a performance baixa, o quão mais lento o JPA é em comparação com o JDBC ñ importa, contanto q ele ainda seja rápido o bastante p/ os casos de uso em q vc o está utilizando. A baixa performance só é um problema quando ela começa a afetar o usuário ou o custo do projeto.
Isso é vdd. Pode ser lento em uma máquina, mas em outra ou outras mais robustas ficariam leves. Depende de quanto se tem ou quanto se quer gastar.
Em que ponto que programar JDBC puro ficaria mais barato do que uma máquina melhor …
@fontomas
Discordo de vc.
Quando abri o topico era e continua sendo pra ter uma ideia se realmente eh interessante e se realmente utilizam ORM em sistemas de meio e grande porte. O q quiz dizer com essa citacao eh relacionar o Hibernate a uma equipe terceira que mantem e desenvolve o FW.
Quanto as questoes de performance e velocidade, acretido q como vah se tratar de um sistema WEB, onde grande parte do processamento fica no servidor isso nao vah influenciar. Eh mais questao de como o sistema fica amarrado.
Vai por mim, recomendo muuuito o hibernate. É o uso das boas práticas da programação. Vc não vai se amarrar em nada pode ter crtz. Com tudo feito da maneira certa vc vai economizar muito tempo na programação. São inúmeras as vantagens. E bem poucas as desvantagens. Pra se ter uma idéia, a versão 3.0 do hibernate já deve ter uns 5 anos pra mais.
Valeu pela contribuicao aluisio, estou fazendo essas perguntas pq estamos pra desenvolver um sistema novo. E quero que jah se inicie dah forma mais correta.
Com a contribuicao q tive nesse topico jah deu pra eu ter uma ideia boa sobre as possibilidades.
Agora vou comecar a postar do Forum de arquitetura, tenho N perguntas.
Mas espero q este topico continue rendendo bons posts.
