Qual framework de persintência utilizar?

boa tarde,

Estou com o seguinte problema, trabalho hoje com o Delphi 5 + Oracle estamos começando a migração para o Java + Web
as regras de negócios estão todas no banco de dados são Triggers, Procedures, Functions, etc.

Nesse meu cenário onde eu tenho tudo gerado pelo banco de dados qual o melhor framework de persinstência ?

Atenciosamente…

Luciano Antunes

Olá…



:smiley:

não entendi ?

o spring para a camada de persistencia.

JPA.

Recomendo Wicket + EJB3

JPA/Hibernate…

Existem várias ferramentas para gerar as classes Java a partir das tabelas do Oracle (Netbeans é uma boa ferramenta, só precisa adicionar o Hibernate, pois o padrão é o Toplink).

[quote=joaosouza]Olá…



:smiley: [/quote]

Viajou!

Sugiro, já que seu entendimento é inicial, partir pro hibernate mesmo, sem anotação pra ralar um pouco nos mapeamentos pra poder entender o funcionamento. Se o caso for corporativo mesmo, tipo sistemas de empresa, partir pro JPA!
E entre HibernateEntityManager (JBoss RedHat) e Toplinks (Oracle), sinta-se a vontade pra escolher!

Na verdade, não importa se vc escolher entre toplink ou hibernate no começo, pois JPA funciona “sobre” eles.

Use a JPA (é só uma interface sobre qualquer framework de persistência), mas dê preferência ao Hibernate, pois as mensagens de erros e os log de erro são mais legíveis no Hibernate do que no Toplink Essentials.

obrigado pessoal pelas respostas,

notei que o hibernate pelo menos para o inicio e a melhor opção já venho estudando ele a uma bom tempo
meu unico medo quanto ao seu uso e referente aquilo que eu havia falado as minhas regras de negocio ficam dentro do banco de dados
um exemplo so para esclarecer eu tenho triggers que geram as chaves primarias para mim, o hibernate consegue se entender com isso.

Cara,

pra esse seu caso aí eu usaria só JDBC. Acho que vc vai evitar boas dores de cabeça fazendo isso. Use no máximo o JDBCTemplate do Spring pra te ajudar…

Hibernate e JPA acho que pro seu caso não agregam muito, pois, pelo que eu entendi, vcs querem continuar a deixar as regras todas no banco, o que não é uma boa prática com Java…mas…

[]'s

Hibernate mais maduro e todos ja sabem como funciona o EJB é bom mas ainda é novidade pouco suporte !

Att

  • Pense 10x se jdbc simples não atende bem ao seu problema.
  • Se não for usar EJB´s, pense em utilizar o Spring DAO support, é bem simples.
  • Se for utilizar ejb3, estude a possibilidade de usar JPA/Hibrnate.

[]´s

até concordo que deveria utilizar o jdbc puro, mas o hibernate me traz uma forma melhor de lidar com os objetos a serem persistidos sem contar com as consultas que sao possiveis fazer com ele.

usar o hibernate no meu caso seria ruim mesmo assim ?

Não é que seja ruim, o que eu aconselho é você avaliar se vale a pena incluir qualquer tipo de complexidade num projeto, e não sair utilizando frameworks pq está na moda.

Mas se houver um margem para aprendizado, sim, vale a pena utilizar o hibernate, é uma ferramenta bem interessante.

[]'s

quanto a margem para o aprendizado não há problema conheco o hibernate já faz um bom tempo venho lendo a sua documentacao vendo exemplos de utilizacao entre outras coisas no modo XML sem anotacoes, mas o que me deixa preocupado e se ele vai me dar a liberdade de manter as minhas regras de negocio no banco de dados.

Visto que vc está migrando acho que hibernate não é o melhor caminho.

O hibernate assume que seu modelo de dados foi desenhado para atender um modelo OO.

O hibernate favorece o desenvolvimento de aplicações oo. Se vc tem muita trigger e regra de negócios no banco é mais provável que sua aplicação seja orientada à banco (por mais que o código seja OO). Isso pode se tornar uma grande dor de cabeça visto que é bem possível que vc tenha de alterar algo no seu modelo de dados para melhor utilizar o hibernate e isso nem sempre é possível. Assumindo que vc não vai alterar seu modelo por causa de alguma necessidade do hibernate vc acabará tendo de utilizar algum recurso “extra” do hibernate pra dar a volta em alguma de suas limitações e isso acaba sempre complicando a manutenção.

Dentro do processo de migração você terá de aprender a utlizar todas as ferramentas (frameworks e bibliotecas) que eleger pro seu arsenal. Sugiro então que vc fique com o simples (que já foi validado pelo mercado), feijão com arroz, pra evitar ondas e modismos que possam aumentar seu risco.

Pra aplicações com essa configuração (orientada à banco) eu sugiro o iBatis/sqlMap.

IMO (e na prática).

Woody

com o ibatis você acha que o meus problemas serão resolvidos deixando toda a regra de negocio no banco de dados ?

Se a regra de negocio está em procs, triggers, etc. Aconselho usar JDBC logo

o iBatis seria a solução então ?

não, não seria tão ruim uma coisa legal do hibernate é que ele lhe permite sempre que for preciso passar por cima do framework.
Apenas analise seu sistema melhor para não acabar usando hibernate (ou qualquer outro framework) só por usar