romarcio wrote:Parece seguir o mesmo conceito usado pelo projeto do Spring Data-JPA.

asaudate wrote:Parece promissor. Só gostaria de tirar algumas dúvidas / fazer críticas:

1) Para a criação do DAO, é necessário implementar uma interface ou ela é criada em Runtime?

2) É 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?

3) 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).

4) 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).

5) 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

Guerr@ wrote:
3. 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.

asaudate wrote:
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.

asaudate wrote:
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.)

rafael_jesus wrote:Opah, no aguardo de um artigo na MundoJ..