Já utilizei muito Hibernate para mapeamento objeto-tabela. Ou seja, quando um atributo do objeto correspondia exatamente a uma coluna da tabela.
Agora, tenho que fazer uma aplicação que produz somente relatório. Os objetos recebem seus valores de consultas (queries) que utilizam várias tabelas. Não existe relação direta entre um atributo dos objetos e uma coluna em tabela.
Em sua opinião, o Hibernate ainda é a melhor opção para uma aplicação de relatórios ou vai o JDBC mesmo ?
Pelo que entendí, na sua aplicação, vc vai trazer informação que está armazenada em várias tabelas e juntar tudo pra montar relatórios, certo?
Usando ORM, vc vai ter que mapear um objeto para cada tabela que represente uma entidade no seu modelo de negócios, fora as tabelas auxiliáres (relacionamento, embeded, etc…).
Pra trazer esta informação com a ferramenta ORM vc vai ter que carregar um monte de objetos na memória e combinar seus valores para jogar no relatório.
Bom… isto não costuma ser muito performático, principalmente se as tabelas contiverem muitos dados. Mesmo considerando todas as otimizações que a ferramenta permita.
Nestes casos, sou a favor de usar JDBC puro mesmo, fazer umas queries ninja com Joins e popular DTOs no formato da consulta mesmo.
Mesmo que vc já tivesse toda uma estrutura de mapeamento ORM, ainda assim, acho que valeria a pena fazer isto em JDBC puro mesmo. Mas é esta é uma opinião geral. Teria que analizar direito o caso em particular e ver o que vale mais a pena.
[]s
otaviojava
Concordo com o colega acima.
Em termo de performance vale a pena optar pelo jdbc.
Até porque usar o hibernate somente para isso não acho nada justificável.
barbon
Olá, falando de desempenho, veja este post que comenta o desempenho do Hibernate com o TopLink, ambos JPA:
