Tiago; excelente!
Já testamos com o NetBeans 6.8, que é inclusive a ferramenta padrão daquí, e
também funcionou perfeitamente.
Também partilho das sua opiniões quanto ao uso dos XMLS's.
Muito obrigado pelas respostas.
Atenciosamente,
Márcio de Figueiredo Moura e Castro
________________________________
De: Tiago Adami <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Terça-feira, 5 de Janeiro de 2010 13:17:41
Assunto: Re: [pgbr-geral] Res: Res: [OT] Hibernate versus JPA ERA: Re: Res:
Res: Res: Res: Uso de Campos Padrões
> No caso então do segundo exemplo do JDev, a ferramenta é que criou os
> beans, e não se utilizou de nenhum Framework, correto?
Correto. A IDE criou os beans usando o padrão da Java Persistence API.
Esta é a idéia da JPA: você escreve os Beans uma vez usando as suas
_annotations_, e o Hibernate, TopLink, EclipseLink e qualquer outra
implementação conseguirá utilizá-los sem a necessidade de
reescrevê-los (por isso é uma API, uma interface, uma referência).
Se você quer entender bem como isto funciona, sugiro dar uma olhada no
NetBeans 6.8 [1]. Com apenas alguns cliques você consegue criar uma
*Persistence Unity* e os Beans de um esquema inteiro de banco de dados
usando qualquer uma das três implementações que citei acima.
> E o Hibernate faz apenas isto (a criação dos beans de persistência) ou
> algo mais?
Se estiver usando a JPA, o Hibernate simplesmente vai usar os Beans
para realizar a persistência. O Hibernate *entende* as Annotations da
JPA.
> A reclamação dos desenvolvedores com relação aos xml gerados pelo
> Hibernate se deve ao mesmo ou à utilização da EJB 2.0?
Antigamente - não sei quais versões exatamente - antes do advento das
Annotations, cada classe precisava ter um arquivo XML de configuração
no formato Hibernate (nada de JPA). Fora os outros arquivos XML
adicionais para conexão com o banco, e não tinham nada relacionado com
EJB - você poderia usar Hibernate com EJB 2.0, mas não era "integrado"
como é hoje com o EJB 3.0+ e JPA (inclusive considero abominável
frameworks construídos 100% sobre arquivos XML. A manutenção é
horrível).
Como já foi dito em algum e-mail anterior, usar um ORM pronto pode
causar um overhead tremendo, com diversas consultas desnecessárias em
prol da facilidade de desenvolver. Por isso sou um pouco - ou muito -
contra usá-los sem uma análise bem profunda.
[1] http://netbeans.org/
--
TIAGO J. ADAMI
http://www.adamiworks.com
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
