Framework Esfinge QueryBuilder - Persistência simples e rápida

This message was edited 2 times. Last update was at 11/02/2012 09:34:42

JMARQ wrote:Como configurá-lo para testar?

Entre no site do framework: http://esfinge.sf.net e no menu documentação, a parte "Funcionalidades Básicas do QueryBuilder" explica detalhadamente como configurar. Veja lá! Não é complicado!

Se tiver alguma dúvida ou dificuldade é só colocar no forum do projeto!

GUJ Master Membro desde: 26/10/2003 12:18:59 Mensagens: 1294 Online

Esse framework exige qual versão mínima de Java/JavaEE? Na empresa usamos Java6 e JavaEE 5, será que é compatível?

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Roger75 wrote:Esse framework exige qual versão mínima de Java/JavaEE? Na empresa usamos Java6 e JavaEE 5, será que é compatível?

Certamente! Ele é compatível com JPA 1, então no seu ambiente vai funcionar sem problemas!

Thread.start() Membro desde: 19/08/2011 23:07:11 Mensagens: 35 Offline

Então você só declara assinaturas de métodos de "pesquisa" ou "busca" (sempre anotando-os) porque os de edição o framework já gera automaticamente pra você até baseado nos relacionamentos entre as classes como coloquei a agregação do Motor dentro do Carro no exemplo ??

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

Olá Guerr@, parabéns pelo trabalho, é uma boa proposta.

Algumas observações que tenho a fazer são:

Concordo com o asaudate sobre a criação de métodos personalizados. Pode ser interessante que eu crie meu próprio método e outros eu deixo para serem implementados pelo framework. Nesse caso, acho que uma classe abstrata seria uma boa opção. Existirão alguns problemas para criar a classe concreta em Runtime no caso da classe abstrata que não ocorrem para a interface. Mas framework é para isso mesmo, resolver problemas.

Cuidado com o uso excessivo de anotações.

Sobre a nomeclatura, acho que QueryBuilder não é um nome adequado. Um query builder deveria ser um construtor de queries, possivelmente usando algum builder pattern (como method chainning). No caso o framework é um construtor de DAOs. Talvez fosse mais interessante o uso como:

Pense em escalabilidade. Para exemplos acadêmicos é fácil fazer um DAO através da interface apenas com um padrão de nomeclatura. Mas e para queries complexas? E se eu quiser fazer algum join? E se eu quiser buscar alguma coleção? Ou uma cláusula where que contenha OR?
É perigoso ter métodos com nomes muito longos ou tenha que utilizar muitas anotações para conseguir fazer a query. Acho que ficaria menos intuitivo do que eu mesmo escrever a query. Se a API servir apenas para situações triviais um método getByExample resolveria grande parte das situações.

De qualquer maneira é uma boa proposta...

Sobre os comentários "pra que invertar outro framework se o hibernate faz a mesma coisa" e "sempre surge um framework prometento mundos e na hora H falham": Bem vindo ao mundo dos criadores de framework.. kkkk

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

cheio_de_duvidas wrote:Então você só declara assinaturas de métodos de "pesquisa" ou "busca" (sempre anotando-os) porque os de edição o framework já gera automaticamente pra você até baseado nos relacionamentos entre as classes como coloquei a agregação do Motor dentro do Carro no exemplo ??

Algumas considerações:

- Os métodos que você chama de pesquisa e busca não necessariamente precisam ser anotados
- Os outros métodos CRUD ele adiciona na sua interface se ela estender Repository
- A questão da agregação será persistido ou não dependendo de como você anotar as suas classes com as anotações do JPA

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

rogelgarcia wrote:
Concordo com o asaudate sobre a criação de métodos personalizados. Pode ser interessante que eu crie meu próprio método e outros eu deixo para serem implementados pelo framework. Nesse caso, acho que uma classe abstrata seria uma boa opção. Existirão alguns problemas para criar a classe concreta em Runtime no caso da classe abstrata que não ocorrem para a interface. Mas framework é para isso mesmo, resolver problemas.

Na verdade penso em você definir uma interface e uma implementação. Daí todas as interfaces que estenderem aquela sua irão adquirir aquela implementação para o método.

rogelgarcia wrote:
Cuidado com o uso excessivo de anotações.

Pode deixar que essa é minha área de pesquisa e já orientei inclusive trabalhos que focavam na legibilidde de código anotado. Em relação a isso tenho duas considerações:

- As anotações costumam ser mais confusas em classes, onde elas se misturam com código. Em interfaces onde tudo é mais declarativo, elas acabam atrapalhando menos.
- Grande parte das anotações serão nos parâmetros para dizer ao framework com interpreta-los. Apesar de haverem muitas possibilidades, acredito que haverá no máximo duas anotações em um parâmetro.
- As anotações para definir termos de domínio tem o potencial de gerar um bom volume em anotações. Apesar disso, a idéia é que os termos de domínio deixem a definição dos métodos mais legível, não precisando que as pessoas recorram a definição deles para entender.

rogelgarcia wrote:
Sobre a nomeclatura, acho que QueryBuilder não é um nome adequado. Um query builder deveria ser um construtor de queries, possivelmente usando algum builder pattern (como method chainning). No caso o framework é um construtor de DAOs.

Na verdade quando o framework começou a ser criado a idéia dele era penas a criação de consultas, porém depois decidiu-se incorporar o DAO também... Daí o nome ficou!

Na verdade existe sim um builder por trás do framework...

rogelgarcia wrote:
Pense em escalabilidade. Para exemplos acadêmicos é fácil fazer um DAO através da interface apenas com um padrão de nomeclatura. Mas e para queries complexas? E se eu quiser fazer algum join? E se eu quiser buscar alguma coleção? Ou uma cláusula where que contenha OR?
É perigoso ter métodos com nomes muito longos ou tenha que utilizar muitas anotações para conseguir fazer a query. Acho que ficaria menos intuitivo do que eu mesmo escrever a query. Se a API servir apenas para situações triviais um método getByExample resolveria grande parte das situações.

Na verdade o framework suporta muitas das situações que você citou como OR, join e inclusive queries onde um parâmetro precisa ser ignorado quando for nulo. Acredito que o Esfinge QueryBuilder consegue deixar algumas coisas bem transparentes e dar opções para quem cria os métodos, como o uso de termos de domínio, alternativas entre colocar coisas no nome do método ou como anotação do parâmetro e etc... Dê uma olhada nos tutoriais que o framework suporta muito mais do que você imagina.

A idéia do framework não é servir para 100% das consultas, mas poupar tempo no desenvolvimento de pelo menos uns 90% delas...

O framework disponibiliza um método chamado queryByExample() na interface repository que funciona como você falou, porém ele é limitado no sentido de que não é possível definir outros tipos de comparação (maior, contains), não é possível definir entre and/or e etc...

Estamos sempre trabalhando para deixar sempre a definição das consultas mais simples. Estamos trabalhando em uma funcionalidade que irá permitir passar JavaBeans como parâmetros, sendo que os parâmetros serão buscados de suas propriedades.

rogelgarcia wrote:
Bem vindo ao mundo dos criadores de framework.. kkkk

Já estou nesse mundo a um certo tempo!

Eu sei que as críticas e sugestões construtivas, como vocês estão dando, são muito importantes para evoluir o framework de acordo com necessidades reais. Porém, é preciso saber filtrar e ignorar quem simplesmente nem lê a documentação do framework e dispara algumas críticas sem muito sentido...

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