Leonardo;
Dá uma olhadida no site da SUN, em
http://java.sun.com/javaee/reference/faq/persistence.jsp.
Pelo que eu entendí, existe a especificação da JPA, e um Framework.
Estou enganado?
________________________________
De: Leonardo Cezar <[email protected]>
Para: Comunidade PostgreSQL Brasileira <[email protected]>
Enviadas: Segunda-feira, 4 de Janeiro de 2010 11:25:49
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.
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> Abraços,
> André.
>
> PS: o hibernate não é baseado no JPA, pelo que me recordo é o contrário.
Considerando que JPA eh apenas a especificacao, como seria possivel
JPA *implementar* alguma coisa???
Realmente estou curioso para entender onde estou equivocado ...
-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.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
