Arquivo Discussoes de Programacao e Tecnologia 
Olá pessoal!
Gostaria de divulgar o framework com o qual tenho trabalhado: Esfinge QueryBuilder -> http://esfinge.sf.net
É um framework open-source que simplifica muito a criação da camada de persistência. Você precisa apenas criar uma inteface com métodos seguindo a convenção de nomenclatura do framework e pronto! Não precisa fazer mais nada!
A opinião e sugestões de vocês são muito bem vindas!
Saudações!
Parece muito interessante!!
Nao conhecia! Vou testar!
Show. Vou testar!
Legal Guerra! A ideia é bem bacana e a documentação é bem simples.
Integração fácil com Spring tb!
Abraços!
Parece seguir o mesmo conceito usado pelo projeto do Spring Data-JPA.
Parece promissor. Só gostaria de tirar algumas dúvidas / fazer críticas:
Para a criação do DAO, é necessário implementar uma interface ou ela é criada em Runtime?
É possível customizar essa interface, para que os DAO’s não sigam a convenção? Digo, não colocar as anotações DomainTerm, mas explicitamente dizer ao framework o que fazer, por exemplo, passando uma consulta JPA?
A parte de testes ainda parece deficiente. Notei que EntityManagers são passados usando a estrutura de serviços da JVM, mas em geral, os testes costumam estar juntos do código (por exemplo, em projetos Maven, o ‘default’ é deixar os testes juntos ao código). Seria mais interessante ele tirar proveito de técnicas como a usada pelo DBUnit, onde é possível criar uma regra para os testes em que, ao invés de criar o EntityManager padrão, usa o EntityManager de testes do Esfinge. Aliás, sendo um framework de persistência, ele poderia até mesmo criar esse ambiente de testes em runtime, baseado em XML’s contendo datasets, por exemplo (idéia, essa, retirada do DBUnit).
Achei que a configuração para Spring poderia ser mais otimizada… pensou em criar uma extension do Spring, com o próprio namespace? Talvez isso torne algumas configurações mais interessantes, como por exemplo, a própria configuração das queries. Um problema que eu enxergo com as anotações é que elas são intrínsecas ao código, ou seja, se você quiser modificar, você tem que recompilar (algo que não acontece com XML’s).
Com o perdão da palavra, mas achei o workflow ainda muito pobre. Você poderia modificar para ele ser mais parecido com o jBPM ou até melhor, para incluir features como persistência dos estados (não encontrei algum lugar dizendo que ele faz isso), interação humana (algo que só pode ser atingido com a persistência dos estados), criação de sub processos, interação com web services, JMS e outros.
Mais uma vez, parece promissor. Se continuar nesse ritmo, tem tudo para se tornar um grande nome entre os frameworks de persistência. O projeto é open source? Está aberto para colaboração?
[]'s
É isso mesmo, porém ele tem alguns diferenciais, como as consultas com suporte a null e os termos de domínio.
Parece promissor. Só gostaria de tirar algumas dúvidas / fazer críticas:
Para a criação do DAO, é necessário implementar uma interface ou ela é criada em Runtime?
É possível customizar essa interface, para que os DAO’s não sigam a convenção? Digo, não colocar as anotações DomainTerm, mas explicitamente dizer ao framework o que fazer, por exemplo, passando uma consulta JPA?
A parte de testes ainda parece deficiente. Notei que EntityManagers são passados usando a estrutura de serviços da JVM, mas em geral, os testes costumam estar juntos do código (por exemplo, em projetos Maven, o ‘default’ é deixar os testes juntos ao código). Seria mais interessante ele tirar proveito de técnicas como a usada pelo DBUnit, onde é possível criar uma regra para os testes em que, ao invés de criar o EntityManager padrão, usa o EntityManager de testes do Esfinge. Aliás, sendo um framework de persistência, ele poderia até mesmo criar esse ambiente de testes em runtime, baseado em XML’s contendo datasets, por exemplo (idéia, essa, retirada do DBUnit).
Achei que a configuração para Spring poderia ser mais otimizada… pensou em criar uma extension do Spring, com o próprio namespace? Talvez isso torne algumas configurações mais interessantes, como por exemplo, a própria configuração das queries. Um problema que eu enxergo com as anotações é que elas são intrínsecas ao código, ou seja, se você quiser modificar, você tem que recompilar (algo que não acontece com XML’s).
Com o perdão da palavra, mas achei o workflow ainda muito pobre. Você poderia modificar para ele ser mais parecido com o jBPM ou até melhor, para incluir features como persistência dos estados (não encontrei algum lugar dizendo que ele faz isso), interação humana (algo que só pode ser atingido com a persistência dos estados), criação de sub processos, interação com web services, JMS e outros.
Mais uma vez, parece promissor. Se continuar nesse ritmo, tem tudo para se tornar um grande nome entre os frameworks de persistência. O projeto é open source? Está aberto para colaboração?
[]'s
Seguem as respostas :
Na verdade você precisa apenas criar a interface. A implementação é criada por um proxy dinâmico.
Não, pois para isso você não precisa do framework… Você pode criar sua própria classe. Nas próximas versões o framework deve suportar a adição de métodos customizados, porém não é esse seu foco.
Em relação aos testes eu discordo de você. O framework foi desenvolvido 100% usando TDD. Ele possui testes de unidade, que usam mocks e tal, e testes de integração, que inclusive usam o DBUnit. Pessoalmente acredito que os testes de unidade devem ficar junto com o código e os de integração em um projeto separado.
A integração com Spring não faz parte do framework em si. O tutorial no site apenas mostra como integrar. Se você puder enviar una forma melhor de integrar, terei prazer em colocar no site!
O framework de workflow é antigo e está descontinuado. Talvez no futuro ele seja retomado, porém não é o foco agora.
Ele é open source sim e qualquer colaboração é bem vinda!
Muito interessante mesmo, vou testar em um proximo projeto!
Eu não estava me referindo ao código do framework, mas sim, ao código que vai ser construído usando o framework. Os frameworks de persistência que já existem são chatos de serem testados, e seria um bom diferencial para o Esfinge prover esse tipo de facilidade.
EDIT: Ah, em relação à necessidade do framework para o uso de métodos customizados, acho importante manter a cabeça aberta. Pode ser que para algum caso específico , seja interessante customizar um método só e outro não. Assim, não seria necessário criar várias artimanhas para contornar o problema. (O Rod Johnson, quando começou o Spring, ia criar só um framework de injeção de dependências. Se ele não tivesse ido mais além, hoje, o Spring seria só isso.)
[]'s
Um teste de classes que usam a persistência seria fácil pois é só mockar a interface criada.
Um teste para ver se a interface está criando as consultas corretas usaria o DBUnit e uma base de dados de testes configurada como uma unidade de persistênia alternativa. Daí você poderia criar um EntityManagerProvider de teste colocando a anotação @ServicePriority(1) que nesse caso ele terá prioridade em relação ao da aplicaçao enquanto estiver no classpath. A questão é que isso não está em lugar nenhum… Vou ver se consigo criar um tutorial mostrando como testar!
Vou fazer isso nas próximas versões (com a estrutua atual não seria complicado), porém não vejo tanta diferença entre colocar esse método adicional na interface do QueryBuilder ou não… A idéia do framework é atender cerca de 90% das consultas de um sistema. Só com isso vai sobrar tempo para as mais complicadas… 
show de bola.
guerra olhei ontem, voltei hj pra ler mais e o site ta off…
UPDATE: VOLTOU rs
Opah, no aguardo de um artigo na MundoJ…
Abrcs e parabéns!!
Opah, no aguardo de um artigo na MundoJ…
Sairá na próxima!
Quando alguém diz que um framework é simples e rápido, leia-se: demorado e trabalhoso.
Poderia argumentar? Você chegou pelo menos a ver como o Esfinge QueryBuilder funciona?
Poderia argumentar? Você chegou pelo menos a ver como o Esfinge QueryBuilder funciona?
Guerra, quando o Marcio_Nogueira falar qualquer coisa do tipo, pode ignorar. O cara só sabe fazer isso da vida dele: criticar. Se for pra ver o funcionamento, ou pelo menos reconhecer o esforço, jamais.
Marcio_Nogueira: Se não tem nada pra falar, fique quieto. Nós não perdemos um tempo precioso das nossas vidas desenvolvendo coisas para facilitar a vida de programadores (como você!!) para depois ouvir críticas sem absolutamente nenhum embasamento.
Tem sempre algém alegando que determinado framework é rápido, simples e produtivo. Já ouvi isso milhares de vezes, agora, na implementação é a maior dor de cabeça para botar funcionando.
[ironia]
Ah, sim. Nesse caso, então, é melhor sair por aí criticando mesmo.
[/ironia]
Agora, fala sério. A imensa maioria dos frameworks em Java são open-source. Se você acha complicado, ou não performático, ou o que quer que seja, porque você não vai lá e arruma? Ou faz o seu próprio? Ou simplesmente muda de framework? Criticar sem ter um motivo pra isso é pior do que não fazer nada, te garanto.
Eu tenho milhares de críticas em relação a vários frameworks que uso. Geralmente, quando eu tenho alguma crítica, eu pego o fonte, corrijo e uso.
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!
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!
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á!
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…
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.
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.
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!
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á!
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…