Estou iniciando os estudos em Hibernate, o EJB 3.0 trouxe a JPA que define uma API para ORM que usa majoritariamente annotations.
Vejo que o Hibernate 3.x suporta tanto a abordagem antiga de mapeamento por XML quanto de annotations do JPA.
Apesar de saber que utilizando as annotations do JPA estou tornando minha aplicação mais flexível caso queira modificar meu framework ORM para algum diferente do Hibernate (fato bem improvável), porém mapeando meus objetos persistentes no próprio código das classes deixou as classes estremamente poluídas e confusas.
Quando se tem apenas uma, duas ou até três anotações ainda vai, mais quando se tem anotações grandes e em excesso a legibilidade fica péssima, sem falar que eu estou de certa forma pondo código de banco de dados junto com minhas classes de negócio, eu acho essa abordagem um tanto quanto esquisita, e estou fortemente inclinidado ao mapeamento antigo do Hibernate através de XML, porém como estou iniciando nisso tudo gostaria de ouvir a opinião de vcs do GUJ.
O que vocês me dizem com relação as questões levantadas?
[quote=bcartaxo]Estou iniciando os estudos em Hibernate, o EJB 3.0 trouxe a JPA que define uma API para ORM que usa majoritariamente annotations.
Vejo que o Hibernate 3.x suporta tanto a abordagem antiga de mapeamento por XML quanto de annotations do JPA.
Apesar de saber que utilizando as annotations do JPA estou tornando minha aplicação mais flexível caso queira modificar meu framework ORM para algum diferente do Hibernate (fato bem improvável), porém mapeando meus objetos persistentes no próprio código das classes deixou as classes estremamente poluídas e confusas.
Quando se tem apenas uma, duas ou até três anotações ainda vai, mais quando se tem anotações grandes e em excesso a legibilidade fica péssima, sem falar que eu estou de certa forma pondo código de banco de dados junto com minhas classes de negócio, eu acho essa abordagem um tanto quanto esquisita, e estou fortemente inclinidado ao mapeamento antigo do Hibernate através de XML, porém como estou iniciando nisso tudo gostaria de ouvir a opinião de vcs do GUJ.
O que vocês me dizem com relação as questões levantadas?
Desde ja agradeço.[/quote]
Eu, particularmente, não gosto de annotations em parte pelos motivos que você apresentou. De qualquer forma, o que acho fundamental é que, independente do mecanismo, os artefatos (classes anotadas ou classes + descritores) sejam gerado de forma automática a partir do banco de dados, quando este já existe, ou de um modelo UML ou ER.
Hoje há ferramentas free e propritárias que fazem esta parte, de forma que esta discussão é, de certa forma secundária.
XML, usado para configurações, fede!
Sem dúvidas use annotations.
Se você mesmo acha bem improvável que ira trocar a framework de ORM, porque se preocupar-se com isso ?
E você pode usar as annotations do JPA, e desta forma poder usar qq ORM compatível com a JPA.
Olha só,
a partir do momento em que você decide usar alguma tecnologia de mapeamento objeto relacional (nao quero entrar aqui na discussão se isso é ou não uma boa decisão) você tem que entender que o framework utilizado precisa ter algum recurso para fazer esse mapeamento. Nenhuma das duas tecnologias que voce mencionou é perfeita (afinal, nada neste mundo de programação é perfeito), e por isso você tem que optar pelo ‘menos ruim’, ou seja, aquilo que vai lhe proporcionar mais produtividade e flexibilidade. Neste caso, sem dúvida, annotations é uma tecnologia melhor. Voce pode, por exemplo, trocar de Toplink para implementação de Hibernate (estou falando de JPA) de uma forma muito fácil, ou até trocar por alguma tecnologia melhor ainda que venha a surgir futuramente. Coisa que seria muito mais dificil de fazer caso voce optasse pelo Hibernate ‘antigo’ usando XML.
Resumindo, neste dilema em particular, o meu voto certamente vai para annotations (JPA).
[quote=bosnic]Olha só,
a partir do momento em que você decide usar alguma tecnologia de mapeamento objeto relacional (nao quero entrar aqui na discussão se isso é ou não uma boa decisão) você tem que entender que o framework utilizado precisa ter algum recurso para fazer esse mapeamento. Nenhuma das duas tecnologias que voce mencionou é perfeita (afinal, nada neste mundo de programação é perfeito), e por isso você tem que optar pelo ‘menos ruim’, ou seja, aquilo que vai lhe proporcionar mais produtividade e flexibilidade. Neste caso, sem dúvida, annotations é uma tecnologia melhor. Voce pode, por exemplo, trocar de Toplink para implementação de Hibernate (estou falando de JPA) de uma forma muito fácil, ou até trocar por alguma tecnologia melhor ainda que venha a surgir futuramente. Coisa que seria muito mais dificil de fazer caso voce optasse pelo Hibernate ‘antigo’ usando XML.
Resumindo, neste dilema em particular, o meu voto certamente vai para annotations (JPA).
Abraço.[/quote]
Pessoal;
Dêem uma melhor estudada na especificação JPA que vcs vao notar que tanto configurações por anotações quanto por XML são aceitas.
Eu estou usando Hibernate Annotations em algumas aplicações, e deixo aqui algumas coisas que constatei:
configurações com anotações realmente é mais prático nos casos simples, mas em casos de herança ou mapeamentos mais complexos, XML é mais fácil de entender.
o JPA é bom no geral, mas em vários detalhes, você tem que fazer configurações específicas para obter o resultado desejado. Exemplo: Pelo JPA, @AssociationOverride não funciona com @Embedded (objetos ‘embedded’ que possuem associações, e não apenas propriedades), mas o Hibernate permite.
algumas coisas só funcionam quando você usa o XML específico! Exemplo: lazy-loading de Blobs em um @Embedded, só funcionou quando configurei no HBM, tentei com todas as anotações possíveis e imagináveis e nada (provavelmente é um bug, mas o fato é que não funciona)
mapeamento ORM, quando vai além do ‘gerado a partir do banco’ (isto é, qualquer mapeamento não trivial) não é tão simples quanto parece, e diferenças entre bancos (Oracle, Postgresql, hsqldb, mysql) e entre providers (Hibernate, Toplink, OpenJPA) afetam consideravelmente o mapeamento (diferença no suporte de features como sequences, etc.). Então, essa coisa de ‘apenas gere tudo a partir do banco’ pode ser uma furada sem volta.
Resumindo, JPA é bom, é bom ter um padrão para funções comuns. Mas quando for fazer um projeto, faça uma escolha de tecnologia (provider) e aprenda-a profundamente, porque com certeza você vai esbarrar com bugs e peculiaridades da implementação, e só vai saber diagnosticar o problema se conhecer bem o que vai por baixo dos panos. Além disso, importantes funções de tunning de performance - como a configuração de cache, por exemplo - são ‘proprietários’ (específicos). Usar apenas o que é ‘padrão’ parece bom, mas quando o padrão nao é suficiente, se limitar a ele é simplesmente burrice.