JDO? ã?

GUJ Hacker Membro desde: 23/03/2003 00:00:00 Mensagens: 6928 Offline

pessoal, quero saber mais a respeito de JDO, onde se aplica, seus pros, seus contras... estou estudando novas maneiras de implementar a persistencia dos vários projetos da empresa, Hibernate, DAOs, Entities, SQLj (q não curti muito..), bancos OO, e me veio a sigla JDO... :cool: alguém ja usou? como q é o lance?

JDO é uma especificação da JCP para a questão de persistência.

Diferentemente do Hibernate, a JDO além de mapear objetos java para banco de dados relacionais, também mapeia para BDOO, arquivos XML, etc.

O JDO tem uma linguagem de consulta bem parecida com a linguagem Java. Tem vários fornecedores, gratuitos e pagos.

O Hibernate, ao contrário, possui só um fornecedor. Mas está parecendo ser um padrão de fato. Muita gente usa-o. Parece que chegou até a influenciar a especificação do EJB 3.0. Não sei ao certo.

Dica 1: Já leu esse tutorial da IBM?
Dica 2: Leia a primeira edição da MundoJava.
Dica 3: Ponha Prevayler na sua listinha de coisinhas lindas para se estudar.

Obs: Desculpem-me pelo patrocínio. Pricipalmente pois sou um leitor muito mais fiel à Java Magazine.

GUJ Hacker Membro desde: 23/03/2003 00:00:00 Mensagens: 6928 Offline

valeu vinci.. atualmente eu to fazendo td em DAOs, ja me interessei pelo Prevayler... só falta um tempo pra estudá-lo... eu sou daqueles q não me acerto com modelo ER, pra mim é td OO, a minha vida é OO, eu acordo de manhã e chamo o método this.levantar() hehehe.. :grin:

JavaTeenager Membro desde: 14/11/2003 00:00:00 Mensagens: 193 Offline

Olá,

Tenho mais de 20 anos de experiência em OE, com uns 10 anos em ExR, estou patinando ainda em java e OO.

Uma das decisões que está pegando é essa de camada de persistência.

Já li muita coisa a respeito, um detalhe que considero relevante com relação às diferenças entre hibernate e jdo, é que o mecanismo de consultas no primeiro é orientada a objetos, mais transparente, enquanto que no jdo só podemos sumeter strings SQL, o que, na minha opinião, acaba com a transparência. Afinal mudando de mssql para mysql, por exemplo, teremos que compilar todas as classes que tenham estas estas strings, já que serima dialetos sql diferentes?

Outra coisa que me chateia é que dependemos de xml. Não faz sentido tanta mistura de padrão!

São apenas dúvidas de um rookie ....

GUJ Hacker Membro desde: 23/03/2003 00:00:00 Mensagens: 6928 Offline

spier, esse caso das implementações de querys em SQL serem diferentes realmente é um problema, o padrão DAO oferece duas soluções, a Factory Method, e a Abstract Factory... a diferenca é q a Method utiliza SQL padrão pra fazer as consultas, sendo assim, roda em todos os bancos, a Abstract utiliza uma implementação diferetente pra cada banco q for usado no sistema.... eu tenho preferencia pela Abstract Factory pq, tu até pode fazer td em SQL padrão, mas, há coisas q por exemplo, em SQL padrão seriam mais lentas do q utilizando SQL nativo num banco como o Oracle... estou estudando novas soluções pra camada de persistencia tb, todos falam do hibernate, nunca o usei, dizem q ele é lento qnd as consultas ao banco são muitas (q é o meu caso)... eu gosto de trabalhar em sistemas totalmente OO, abstraindo toda relação de tabelas no modelo ER... :cool:

spier wrote:Olá,
(...) um detalhe que considero relevante com relação às diferenças entre hibernate e jdo, é que o mecanismo de consultas no primeiro é orientada a objetos, mais transparente, enquanto que no jdo só podemos sumeter strings SQL, o que, na minha opinião, acaba com a transparência. Afinal mudando de mssql para mysql, por exemplo, teremos que compilar todas as classes que tenham estas estas strings, já que serima dialetos sql diferentes?
(...)

Ei! Nem hibernate, nem JDO trabalham* com SQL! Hibernate trabalha com HQL(Hibernate Query Language) e JDO trabalha com JDOQL(JDO Hibernate Query Language).

Ambos servem justamente para isolar a sua aplicação de qualquer banco de dados.

spier wrote:
Outra coisa que me chateia é que dependemos de xml. Não faz sentido tanta mistura de padrão!

Faz sentido usar XML sim!

Com XML você isola as configurações que ficariam no seu código. Isso facilita a manutenção, pois você não vai ter que ficar procurando no código onde tem setar uma variável, mudar um parâmetro na chamada de método, chamar outro método, etc. Além disso, XML possibilita que você possa alterar as configurações sem recompilar seu código.

* trabalham no sentido que exigem que você escreva SQL. No fundo, todas essas implementações geram SQL para cada banco de dados...

JavaTeenager Membro desde: 14/11/2003 00:00:00 Mensagens: 193 Offline

vinci wrote:

Com XML você isola as configurações que ficariam no seu código. Isso facilita a manutenção, pois você não vai ter que ficar procurando no código onde tem setar uma variável, mudar um parâmetro na chamada de método, chamar outro método, etc. Além disso, XML possibilita que você possa alterar as configurações sem recompilar seu código.

mas todas estas funcionalidades cabem num grupo de classes específicas. Para ambientes internos, é algo que, se bem feito, se faz uma única vez.
Para distribuições, se faz uma vez para cada "plataforma".

<vinci_defensor_fanático_que_não_dá_o_braço_a_torcer>

Como garantir que o usuário do seu framework irá "fazer tudo direitinho"? Usar XML é mais que uma opção. É uma decisão estratégica.

</vinci_defensor_fanático_que_não_dá_o_braço_a_torcer>

Notícias, artigos e o maior fórum brasileiro sobre Java