Criterio em DAO

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Gostaria da opinião de vocês.
Como passar criterios de busca para um DAO de uma manira mais elegante.

ex:

Como eu implementaria o método consultar se quisesse consultar um funcionário pelo código do edificio, sendo que o mesmo é da classe departamento e não da classe funcionário.
O mais coerente que fizesse a busca pelo FuncionarioDAO, pois estou buscando funcionarios, mas baseado em um atributo de uma classe que está agregada a classe funcionário (departamento).
obs:
Não eu acho legal usar aquele hql na camada de negócio pois viola a lei d abstração de persisencia.

Se você tem um objeto Departamento dentro do funcionário, não vejo problemas em utilizar o 'atributo do atributo' (considerando que na tabela você teria essa estrutura também), como:

Aqui tem uma discussão mais ou menos acerca disso:
http://www.guj.com.br/posts/list/30/22420.java

This message was edited 1 time. Last update was at 13/04/2005 14:39:58

Pode ser.
Mas não ficaria deselegante.
Ter que ficar instanciando a classe funcionario e subclasses para fazer uma consulta.
Estava pensando em algo como

olhando rapidamente, prefiro como o Rafael postou, me parece um pouco mais OO.
so tiraria o sql de detro do DAO.

[]'s

This message was edited 1 time. Last update was at 13/04/2005 14:51:24

Bem, eu optaria por receber o objeto, porque passando parâmetros eu teria de ter um método pra cada parâmetro. E se eu tivesse 50, 100, 1000 parâmetros...
E como foi dito no outro tópico, não é interessante espalhar os dados da implementação do objeto por aí, seria legal se o DAO não conhecesse como é a implementação do Funcionario.(Se bem que passando o objeto, dentro dele ele acabaria sabendo que ele possui um atributo chamado Departamento que possui um id.)

olhando rapidamente, prefiro como o Rafael postou, me parece um pouco mais OO.
so tiraria o sql de detro do DAO.

E colocaria onde o SQL?Arquivos properties?

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Compo vocês falaram se eu tiver muitos critérios tem problema.
É bom que fica bem mais flexivel da forma do Rafael.

Enquanto a sql não veria problemas...

sem usar frameworks, colocaria a principio em properties.
se as consultas se tornassem muito complexas, em xml's

[]'s

Agora eu fiquei curioso, como você faria isso em xml´s?
É que nunca vi desta forma, só em properties.

This message was edited 1 time. Last update was at 13/04/2005 15:20:00

To começando ficar interessado também.
Mas outra pergunta.

E no caso de consultas com:
- agrupamento
- com restrição de campos (apenas alguns campos da classe)
- campos nulos (ver se o campo é nulo em primitivos)

This message was edited 1 time. Last update was at 13/04/2005 15:20:56

tem outras formas, mas eu ja fiz carregando as consultas do xml em beans e tenho uma classe metodos estaticos que me retornam essas consultas.
no xml fica com tags mais ou menos assim:

usando PreparedStatement vc substitui os parametros.
é por ae....

[]'s

<EDIT>
claro que depende das consultas, nesse caso eu tinha consultas bem chatas, que em arquivos properties ficariam dificeis de manter.
</EDIT>

Eu precisaria criar um método de consulta para cada consulta diferente?
Por exemplo:

Não tem alguma forma de abstrair mais essa consulta, ou seria melhor mudar toda parte de persistência para utilizar algum framework, como Hibernate?

jgbt, qual API vc utiliza para parsear os XML's para seus Beans?

a ideia é essa, cada metodo deve fazer somente o que é responsabilidade dele.
ter um metodo generico, mas cheio de if's p/ montar a consulta, não me parece legal.

eu usei o castor, um framework p/ xml, não lembro o linnk agora, mas da uma procurada no google que vc deve achar.

[]'s

jgbt wrote:tem outras formas, mas eu ja fiz carregando as consultas do xml em beans e tenho uma classe metodos estaticos que me retornam essas consultas.
no xml fica com tags mais ou menos assim:
<consulta codigo="codigo1" sql="SELECT 1, 2 , 3 FROM table WHERE parametro1 = ?"> </consulta>

Não entendi qual a diferença de colocar uma consulta no XML ou em um properties. O que você ganhou com esse XML? (Além da necessidade de ter que fazer o parser!

)

[]'s
Marco Campêlo

é que eram comsultas complexas, com varias subqueries.
ficava ruim de visualizar a consulta em um properties, numa unica linha.
e o bean tinha outras propiedades alem da query, que ficavam facil de mofificar, sem recompilar o codigo.

[]'s

Se seus DAOs possuem tantos métodos de pesquisa diferentes que você está ficando maluco, considere seriamente a adoção de um framework O-R decente.

Eu já fui a favor de DAOs com "linguagens de consulta", mas isso é completamente contra o uso que se deveria fazer de um DAO em si. Um DAO deveria ser usado quando você tem X consultas no banco, e no máximo, quem sabe, vai passar para 2X em alguns meses, mas não mais que isso. Uma das grandes vantagens (se você cosntruir DAOs bonitinhos) é que passar essa implementação para um Hibernate (exemplo, nenhuma lei) não é muito complicado mantendo a API do DAO.

Um outro ponto onde DAOs são problemáticos é montar relacionamentos. Muitas vezes voê acaba com métodos cheios de gambiarras para evitar trazer toda a sua estrutura de objetos do banco e ao mesmo tempo evitar NullPointerException.

Resumindo:

Use DAO quando você não vai rpecisar fazer nada além de CRUD. Se você precisa emitir relatórios ou fazer buscas complexas e parametrizadas, pode fazer com que estas operações com o SBD sejam efetuadas por outro componente, e deixem os DAOs no

E meia dúzia de métodos de busca. Aliás: procure reutilizar o máximod e código dentro de um DAO, cuidade no modo como transforma um ResultSet em objeto, faça de maneira que todos os métodos de pesquisa possam reutilizar este método se possível.

Notícias, artigos e o maior fórum brasileiro sobre Java