>   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

Responder a