Relational - ORM framework

6 respostas
L

Olá.

Procuro entusiastas para um framework ORM (de nome “Relational”) baseado em geração de código capaz de superar outros frameworks em desempenho, portabilidade e facilidade de uso. A abordagem foi “desenvolver” uma linguagem genérica (GQL), de sintaxe idêntica a SQL, para aproveitar o conhecimento em SQL que a maioria dos usuários têm, e traduzi-la para o SQL específico de cada banco. Ou seja: o usuário, além de usar os DAOs gerados automaticamente pelo framework, ainda pode escrever queries em GQL que são traduzidas automaticamente para o SQL específico do banco em uso. Existem outras opções ainda, mas não detalharei aqui.

E o principal: utilizar GUIs para gerenciar a estrutura do banco, atualizar automaticamente a estrutura do banco, comparar estruturas de banco, etc… Essa parte acho que é a mais interessante, já que a maior reclamação que ouço e faço sobre outros frameworks é o exagero de XMLs que se precisa manter.

O código do framework ainda não foi publicado, pois desconheço o número de interessados no assunto. Se existirem interessados, penso em liberar o source completo. O endereço do projeto no SourceForge é http://sourceforge.net/projects/relational/.

Se existirem interessados, aguardo contatos.

Abraço.

6 Respostas

T

Seria algo parecido com o hibernate? =)

L

Digamos que seria um “substituto de maior performance e maior facilidade de uso”.

T

Tenho algumas considerações sobre o assunto…
Acho bacana a sua idéia de desenvolver um framework ORM. Porém, começar do zero (reinventar a roda) não acho válido.
Talvez seja interessante vc estender o hibernate de maneira que atenda suas necessidades.

O hibernate já é um framework de alta performance. Com ele vc pode utilizar mecanismos de cache que fazem sua aplicação voar.
Com relação às “complicações devido ao excesso de XML”, atualmente, temos a possibilidade de utilizar annotation em vez de XML. Ou seja, bem mais simples e intuitivo.

Enfim, o hibernate já é um framework bem aceito na comunidade e tem uma grande empresa que o mantem (JBoss).

Acho que é mais negócio pra vc entendê-lo e adapta-lo conforme sua necessidade.

L

Olá.

Conheço o Hibernate, inclusive com annotations. Trabalhei os últimos dois anos e meio com Hibernate, na verdade. Mantive aproximadamente 5 sistemas grandes (e alguns menores) em Java utilizando JSP, bibliotecas próprias e bibliotecas open source, sendo Hibernate a única biblioteca open source que causava problemas e que não me permitia dormir em paz.

Sim, o Hibernate proporciona alta performance se for utilizado no modelo-exemplo. Saia desse modelo para um modelo real e terás problemas. A experiência me provou isso.

A proposta está longe de ser a “reinvenção da roda”. Acredito que as muitas dificuldades que enfrentei com Hibernate também foram e são enfrentadas diariamente por muita gente (vide a quantidade de posts em fóruns relatando dificuldades). Essas dificuldades repetitivas, na minha opinião, provam que a roda permanece quadrada.

Enfim: procuro entusiastas para desenvolvimento de um novo framework, brasileiro, que seja mais simples, menor, de desempenho superior ao Hibernate, possua interface gráfica para as tarefas onde for aplicável, etc… Na verdade o núcleo desse framework já existe, e já roda com sucesso em produção em um sistema que mantenho. Esse mesmo sistema utilizava Hibernate há uma semana, e executava a 1/10 do desempenho que executa hoje.

Se existirem interessados em testá-lo, entender como funciona, compartilhar ideias e conhecer suas diferenças em relação aos já existentes, aguardo contato.

franciscossouza

Por que não usar JPA e, consequentemente, a JPQL?

Quais as propostas em relação ao Toplink? Nunca gostei do Hibernate mesmo, muito trabalhoso, chato. Toplink mais usável, simples e tem melhor desempenho! :wink:

Se a proposta é fazer um ORM, criar pontos de comparação só com o Hibernate já é um erro ;~

Grinvon

Mesmo existindo soluções como Hibernate, JPA e iBatis, nada impede de se criar mais um ORM. E estou de acordo com lfarcaro, o Hibernate é um framework que veio para facilitar a nossas vidas, porém trazer consigo outros problemas que antes não existiam.

#1
Uma vez tive um problema com os listeners de um JPA, ao mapear e chamá-los de forma correta, eu não sabia que uma chamada de uma mesma sessão de EntityManager pudesse ser utilizado para persistência dentro dele, detalhe, perdi nessa brincadeira quase UMA semana procurando respostas nos fóruns e a minha sorte é que um hibernate developer insider me ajudou dizendo que isso era bug do hibernate. Minha solução foi criar uma nova EntityManager.

#2
Problemas com classes de testes usando flush e persist, o mesmo código era executado N vezes em uma classe de testes, rotinas simples, criava-se um um bean, o populava, persistia ao banco, trazia esse objetivo pelo find atualizava e usava-se o flush, horas funcionava e outras horas não, algo surreal.

#3
Problema com o StaleStateException:

Solução que “encontrei” para esse problema, usar a nativeQuery para fazer meu update, já que em uma determinada entidade o hibernate “não achava algo para persistir”, de um auto-relacionamento, ele simplesmente não conseguia persistir.

#4
Trabalhar com batch? Melhor pegar um driver JDBC da vida, como da Oracle (além do thin, existe um próprio para esse fim) e criar o seu batch update na mão.

Bom, como falei, o Hibernate-JPA e cia vieram para resolver uma série de coisas, mas será que valeu 100% o esforço? De qualquer forma é um projeto ousado de ampla magnitude.

Criado 19 de julho de 2009
Ultima resposta 19 de jul. de 2009
Respostas 6
Participantes 4