Duvida sobre Dao e Criteria

Olá, estava lendo um post sobre DAO aqui e vi um usuario reclamando do fato de ter que fazer varios metodos find como findById(), findByName(). Bom, alguem sugeriu que se criasse um esquema de Criteria para resolver o problema. O que fiz foi criar uma interface Criteria com metodos execute e outros para recuperar informações da criteria e, a partir daí, criei uma implementação SQLCriteria. Isso simplificou bastante os DAOs mas, agora estou com uma duvida: onde eu devo criar os objetos Criteria?!

Nos DAOs parece meio sem sentido. Nas classes de negocios que usam os DAOs parace-me ser um erro crasso já que eu estarei ligando as classes de negocios a implementações especificas de Criteria e, portanto, a implementações especificas dos DAOs. Como eu resolvo isso?! Alguem tem alguma ideia?!

Até.

acho que deve criar nos DAOs mesmo, pois assim, o um DAO pode criar um SQLCriteria, outro um HibernateCriteria, …
e assim por diante, o DAO sabe que tipo de criteria ele trabalha :slight_smile:

[quote=“urubatan”]acho que deve criar nos DAOs mesmo, pois assim, o um DAO pode criar um SQLCriteria, outro um HibernateCriteria, …
e assim por diante, o DAO sabe que tipo de criteria ele trabalha :-)[/quote]
Urubatan, mas como eu digo para o DAO, por exemplo, no metodo find, que tipo (não do ponto de vista de classes, mas de parametros na criteria) de criteria ele deve usar?! Passo um parametro a mais indicando?! Pergunto isso porque pensei no metodo find apenas assim:

public Tipo find(Criteria criteria) {
...
}

Então, como dentro do find eu decido que o Criteria deve executar uma busca por id e não pode name?! Vc pode dar um exemplo?! Nem precisa manter o find do jeito que está que eu tento refatorar sem broncas… :wink:

Até.

Oba,

Esse era meu post :oops: … mas eu aprendi :shock:

quer dizer, to tentando … eu desenvolvi com idéias tiradas do Hibernate, um pouco melhoradas :wink: ehehe sei lá, ficou mais fácil de construir blocos OR misturados com AND … no fim das contas tenho um grafo valorado e a implementacao apenas tem que saber ler o grafo e traduzi-lo pra sua linguagem (SQL, Ars, o que for)

Assim que eu terminar o esquema (vou tentar esse fim de semana) eu posto melhor :smiley:

Hmmm… ideia rapida, eu mal li o post: se usar a API de criteria nao fica legal nem na regra de negocio nem no dao, pq nao criar uma camada entre os dois? Chama de, sei lah, QO (query object) :stuck_out_tongue:

Hummm … ao inves de APP -> DAO -> QUERY ter APP -> QUERY -> DAO ?!? Cadê a vantagem?

De qq jeito ou o DAO tem que conhecer o Criteria ou o Critera conhece o DAO (falando em implementacoes mesmo) ou não entendi direito?

Pois é, eu bem que pensei nisso. Mas não cheguei a tirar conclusões sobre as implicações de se fazer assim. E tambem, acho que acabo perdendo a vantagem de usar Criteria. Ora, se eu fizer uma camada entre os dois, as classes com as regras terão uma serie de metodos (findById, findByName and so on) e a camada entre as duas teria que fornecer esses metodos tambem para poder criar corretamente as criterias. Bom, pensando assim, creio que seja melhor então colocar logo esses metodos nos DAOs. Ou não?! Como vc imaginou essa camada, cv?!

Até.

Apenas para informar, o post do smota que eu havia lido é esse:
http://www.guj.com.br/forum/viewtopic.php?t=6734

off: Ei, smota, essa frase na sua assinatura é de Galileu, certo?! Bem legal mesmo.

Até.