Não estou criticando sem motivo, simplesmente quando surge um novo frameworks falam maravilhas, prometem de tudo até enxugar gelo!
Quem se fode é o programador que tem que botar esta bosta para funcionar.
Foram vocês que fizeram esta merda? Estou fora, não perco meu tempo com lixo!
[quote=Marcio_Nogueira]Não estou criticando sem motivo, simplesmente quando surge um novo frameworks falam maravilhas, prometem de tudo até enxugar gelo!
Quem se fode é o programador que tem que botar esta bosta para funcionar.
Foram vocês que fizeram esta merda? Estou fora, não perco meu tempo com lixo!
[/quote]
Não está criticando sem motivo? Você já olhou pelo menos o site do framework?
Está prometendo enxugar gelo? Cadê? Onde está escrito?
Quem se fode é o programador? O que você sugere, fazer na mão?
Se fui quem fez? Não, não fui eu, foi o Guerra - que, por falar nisso, é doutor em Ciências da Computação pelo ITA. Você consegue fazer melhor?
Insisto: criticar (e, depois, dar desculpas esfarrapadas pela crítica) é muito fácil. Difícil é dar alternativas e/ou ajudar e/ou fazer melhor.
Legal… mas para que vou usar ???
Eu sinceramente não vi uma ultilidade para mim , parece um tentativa de fazer os finders dinamicos do Grails… Bom prefiro o Grails.
Mas legal a iniciativa , deve ter sido divertido desenvolver…
Eduardo , então basta declarar java beans (sem métodos) e seus relacionamentos que o framework gera um CRUD ?
Por ex. para
class Carro {
private Motor motor;
private Pneu pneu1;
private Pneu pneu2;
private Pneu pneu3;
private Pneu pneu4;
}
class Motor {
private double potencia;
}
class Pneu {
private String marca;
}Obrigado desde já!
[quote=rdgms]Legal… mas para que vou usar ???
Eu sinceramente não vi uma ultilidade para mim , parece um tentativa de fazer os finders dinamicos do Grails… Bom prefiro o Grails.
Mas legal a iniciativa , deve ter sido divertido desenvolver…[/quote]
Voce ja imaginou um mundo onde alguem não quisesse usar o grails, mais tivesse interesse nos finders dinamicos?
Como configurá-lo para testar?
Por que reinventar a roda se você pode focar no design do carro e no motor?
http://www.hibernate.org/
Acho muito legal a sua inciativa, é assim que nascem novos frameworks de persistência. Mas ferramentas open-source já consolidadas estão aí afora para evitar retrabalhos com a camada de persistência.
Algo novo seria uma abstração de regras de negócio, já que a abstração da camada de dados está praticamente mega-consolidada.
[quote=doravan]Por que reinventar a roda se você pode focar no design do carro e no motor?
http://www.hibernate.org/
Acho muito legal a sua inciativa, é assim que nascem novos frameworks de persistência. Mas ferramentas open-source já consolidadas estão aí afora para evitar retrabalhos com a camada de persistência.
Algo novo seria uma abstração de regras de negócio, já que a abstração da camada de dados está praticamente mega-consolidada.
[/quote]
Nenhuma roda foi reinventada! O Esfinge QueryBuilder funciona em cima do JPA (podendo-se utilizar o Hibernate ou outra implementação). Ele economiza o código que você precisaria criar para a geração de consultas, fazendo isso interpretando a assinatura de um método de uma interface. Além disso a idéia é que o Esfinge QueryBuider forneça uma funcionalidade idêntica para bancos de dados não-relacionais, fornecendo inclusive uma camada de abstração a alternativa de persistênca adotada, o que está fora do escopo do Hibernate e frameworks de mapeamento.
Por dizer isso tenho certeza que não leu a documentação do framework no site. Gostaria muito que desse uma olhada para ver se muda de idéia!
[quote=cheio_de_duvidas]Eduardo , então basta declarar java beans (sem métodos) e seus relacionamentos que o framework gera um CRUD ?
Por ex. para
class Carro {
private Motor motor;
private Pneu pneu1;
private Pneu pneu2;
private Pneu pneu3;
private Pneu pneu4;
}
class Motor {
private double potencia;
}
class Pneu {
private String marca;
}Obrigado desde já!
[/quote]
Na verdade para que o framework implemente o CRUD você precisa que suas classes sejam mapeadas para o banco de dados usando JPA. No caso, você precisaria pelo menos de anotar as classes com @Entity e ter um campo com @Id.
Porém a grande vantagem do framework é gerar as consultas a partir da assintatura de métodos de uma interface. Exemplo:
List getCarroByMotorPotencia(double potencia);
List getCarroByPneu1MarcaOrderByMotorPotencia(String marca);
Só a declaração do método seria suficiente para o framework!
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!
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!
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 ??
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:
PersonDAO dao = DAOFactory.create(PersonDAO.class);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 
Algumas considerações:
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.
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:
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… 
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.
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…