Pessoal,
Estou fazendo uma aplicação SWT com hibernate e percebi que todas as vantagens que o hibernate tem pra app web, não faz sentido no desktop. Ex: pool, cache, session etc. Estou correto?
Discordo, vc pode fazer tudo isso quem sabe usando um lado cliente com a aplicação SWT e um lado com o servidor usando um módulo EJB.
Assim vc tem todos os recursos
[]'s
Concordo com os dois, se for uma aplicação desktop puramente local, como geralmente é, então não precisa de muitas dessas funcionalidades pra escalabilidade, pq geralmente só vai ter um usuário mesmo…
Se for usar EJB remoto a coisa já muda de figura, mas aí cache, pool, etc, estariam no servidor, só mudaria o cliente, que no caso não seria o browser, seria o cliente swt =D
Discordo, a funcionalidade básica do hibernate ( ou qualquer outro framework ORM ) é facilitar este mapeamento, aumentando a produtividade e facilitando a vida, muito menos SQL do que fazer na mão.
Estas outras funcionalidades como cache, pool, session, daí realmente depende da sua aplicação. Eu trabalhei num projeto SWT de monitoramento, onde estes recursos foram muito importantes, era uma aplicação multi-thread. Mas mesmo se não fosse, pelo fato acima certamente o hibernate traria muitos ganhos.
eduacsp: Eu devo ser um dos poucos desenvolvedores que nunca usou Hibernate fora do ambiente Desktop (não entendo nada de Web…) Como você falou, há recursos que fazem mais sentido em ambiente Web mas não tanto para Desktop, tais como o cache de segundo nível e pools contendo grande quantidade de conexões. Porém, como tantas outras coisas nessa vida, sempre surgem exceções: há pouco tempo precisei executar três consultas SQL ao mesmo tempo num aplicativo Desktop com Hibernate, e nesse caso o pool de conexões veio bem a calhar.
Termino reforçando o comentário do lap_junior: mesmo que você não use determinados recursos em ambiente Desktop, os objetivos básicos do Hibernate são diminuir a dependência de SQL manual e aumentar a produtividade do desenvolvedor, e isso ele faz muito bem.
Depende de cada caso. Quando existem mts tabelas com mts FKs fica dificil tanto mapear quando dar manutenção. No meu caso, é uma aplicação de simples pra média complexidade, então não é difícil. Mas eu vejo que as vantagens do hibernate são mt mais cache, session e pool do que mapeamento.
Pra deixar a aplicação rápida eu tive que desativar quase td que o hibernate tem de bom, tirando o a session. Sinceramente estou pensando em colocar o velho e bom jdbc la.
Sem problema, no seu caso vejo que JDBC é uma boa saída. Mas eu ainda incluiria o Hibernate, e executaria meus Statement’s em cima de um Connection obtida via SessionFactory.getCurrentSession().connection(). Outra via é usar SessionFactory.getCurrentSession().createSQLQuery().
Achei que o comentário era somente sobre as funcionalidades ligadas diretamente à escalabilidade pra acesso simultaneo de vários usuarios como cache, pool de conexões…
Eu sempre uso hibernate/jpa mesmo nos projetos pequenos, as vantagens de abstração do banco, principalmente quando se tem que fazer um refactoring no modelo fazem valer a pena a possível perda de performance em praticamente todos os casos…
Em questão de manutenibilidade o hibernate ganha do jdbc fácil também… acho que o único ponto em que fico com o pé atrás com o hibernate é pra geração de grandes relatórios =D