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.
[quote=asaudate]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
[/quote]
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!!
[quote=rafael_jesus]Opah, no aguardo de um artigo na MundoJ…
[/quote]
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?[/quote]
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.