Ok; só dando um pitaco rápido quanto ao JPA:
Segundo o site da SUN, em
http://java.sun.com/javaee/reference/faq/persistence.jsp:
Q: What are the advantages of the Java Persistence API?
A: The Java Persistence API draws upon the best ideas from persistence
technologies such as Hibernate, TopLink, and JDO. Customers now no
longer face the choice between incompatible non-standard persistence
models for object/relational mapping. In addition, the Java
Persistence API is usable both within Java SE environments as well as
within Java EE, allowing many more developers to take advantage of a
standard persistence API.
Q: Why didn't you adopt Hibernate or JDO as the persistence API?
A: We chose to combine the best ideas from many sources in the new
persistence API and create a practical, easy to use API to meet the
needs of a majority of Java EE and Java SE community members. The
Java Persistence API is not based on any single existing
persistence framework but incorporates--and improves upon--ideas
contributed by many popular frameworks, including Hibernate, TopLink,
JDO, and others.
Atenciosamente,
Márcio de Figueiredo Moura e Castro
________________________________
De: Tarcísio Sassara <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Domingo, 3 de Janeiro de 2010 4:25:34
Assunto: Re: [pgbr-geral] Res: Uso de Campos Padrões
2010/1/2 Andre Fernandes <[email protected]>:
> 2010/1/2 Tarcísio Sassara <[email protected]>
>>
>> 2010/1/2 Leonardo Cezar <[email protected]>:
>> > 2010/1/1 Tarcísio Sassara <[email protected]>:
>> >> Ainda não conheço uma biblioteca/framework ORM que faz uso adequado de
>> >> chaves naturais compostas.
>> >
>> > php: doctrine, propel;
>> > python: SQLAlchemy;
>> > ruby: DataMapper;
>> > java: qualquer framework baseado na porcaria do JPA, por exemplo
>> > hibernate;
>> >
>> > Abraço!
>> >
>>
>> Opá,
>> Da lista conheço o SQLAlchemy, o Propel e o Doctrine.
>>
>> Acho que o Doctrine superou o Propel.
>> E no site do Doctrine diz: "Avoid composite keys"
>>
>>
>> http://www.doctrine-project.org/documentation/manual/2_0/en/best-practices#avoid-composite-keys
>>
>> Se da o suporte mas não recomenda o uso, não é legal.
>>
>> O ORM provido pelo Django também não faz direito (faz tempo que não
>> dou uma olhada).
>>
>>
>> Para novas aplicações criadas isso não é muito problemático. É só
>> seguir as convenções, mas quando é preciso migrar deve dar uma dor de
>> cabeça.
>>
>>
>
> Boa tarde,
>
> Honestamente, o uso de ORMs é um assunto deveras polêmico.
Yah! Muito! Existe situações que eles podem ser ignorados ou bem úteis.
>
> Eu, pessoalmente, sou contra. Não considero boa prática ter a estrutura do
> banco na aplicação, não vejo razão de transportar a mesma para a aplicação,
> ela não precisa saber quais são as tabelas que se usa no banco. A modelagem
> do banco de dados pertence ao banco de dados.
Concordo especialmente com a seguinte afirmação: "Não considero boa
prática ter a estrutura do banco na aplicação".
Existe um problema muito grande. Um pecado que os desenvolvedores
estão cometendo:
Estão tirando a regras do negócio do banco de dados e colocando-as na aplicação.
> E também já vi muitos problemas de desempenho e más implementações quanto a
> muitos aspectos referentes ao banco em diversos ORMs de mercado. Incluindo
> Doctrine, Propel, Hibernate, entre outros. Mas isso é minha visão pessoal.
Alguns problemas são pelo mal uso mesmo.
Por exemplo: Deixar no modo debug onde é refeito toda hora o mapeamento.
> Por outro lado, tenho amigos que são excelentes desenvolvedores (eu sou
> analista de dados, mesmo sabendo programar não tenho visão de programador)
> que adoram o uso de ORMs. Muitos deles gostam de doctrine para PHP e
> Hibernate para Java. Mesmo ao apontar os problemas que encontrei nessas
> ferramentas, eles consideram que esses ORMs são ótimas alternativas e ajudam
> muito. Mesmo discordando tenho de aceitar a opnião deles pois assim é o
> mundo do desenvolvimento de software: há diversas frentes, e quase nunca
> apenas uma está correta.
Depende muito, se você iniciar um projeto do zero e seguir as
recomendações das bibliotecas você consegue
um ótimo desempenho. O pior caso é quando você resolve adotar a
ferramenta depois de o modelo estar pronto.
Assim eu concordo. Fica uma droga.
> Eu, pessoalmente, considero melhor prática usar visões e procedures para
> acessar dados do banco ou mesmo alterá-los, com poucas excessões. O programa
> não precisa saber o que está em cada tabela, precisa apenas solicitar que,
> por exemplo, insira um novo cliente e mandar os dados dele. E depois precisa
> ler os dados do mesmo, não se preocupando se tem 1, 2, 3, ou mais tabelas
> que compooem essa informação.
> Essa é a minha visão, é como faria. Mas se entrarmos em discussão quanto a
> isso a coisa vai longe, é um assunto muito polêmico.
O problema é que em uma aplicação fazemos isto direto. Inserimos e
pesquisamos registros em muitas
sessões (telas). Se não abstrairmos, acabaremos repetindo muito
código. Coisas como abrir e fechar conexão.
E ainda existe o problema dos sistemas que devem ser portáveis.
>
> PS: o hibernate não é baseado no JPA, pelo que me recordo é o contrário.
>
Ah! Isso é um assunto interessante. Realmente, na prática, o JPA veio
depois do Hibernate mas conceitualmente o Hibernate é baseado no JPA.
JPA é uma especificação.
A JPA foi uma tentativa de especificar uma camada de persistência.
(Não sei dizer se foi uma tentativa bem sucedida)
Hibernate é uma implementação.
O hibernate é o cara realmente. Ele é baseado na especificação JPA.
Quando os caras do Java começaram a criar a JPA usaram como base o Hibernate.
Foi o caso clássico da implementação que veio primeiro da especificação.
--
Tarcisio F. Sassara
_______________________________________________
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
