ae galera, gostaria de abrir aqui uma discussão sobre essas duas maneiras de colocar seu codigo SQL nos repositorios da aplicacao.
-> 1ª:
Colocar o código SQL diretamente dentro dos métodos das classes de repositório (inserir, remover, atualizar, ...)
-> 2ª
Definir uma interface separada com constantes do tipo String que sao os comandos SQL do repositorio e entao fazer a classe implementar essa interface e usar as constantes dentro dos metodos.
opinem ae galera!
abraços! 
Não uso mais SQL, mas particulamente não vejo problema em deixar os SQLs nos métodos. Se você acha isso feio e quer separar, acho melhor criar um arquivo properties com as queries do que criar constantes.
[]'s
Rodrigo Auler
Qual a vantagem da segunda abordagem?
eu acho que organizacao!
Eu uso hibernate então dificil escrever SQL, mas a segunda forma parece ser mais organizado, apesar de poder aumentar consideravelmente o numero de interfaces num sistema maior (mas tb num sistema maior organizar persistencia na mão, parece meio masoquista, hehehe)
Pq vcs não usam Hibernate? Aí vai ter gente falando dos XML’s, aí eu tomo a liberdade em já me antecipar essa possível resposta em sugerir JPA.
Vai usar SQL ? use DAO…
Pattern que garante que os codigos SQL não virem um virus em sua app java , concentrando tudo em um unico local…
Pense em Utilizar JPA, voce usa um acronimo do SQL , chamado EJB-QL que na minha opiniao… dispensa o uso de DAO’s , devido ao mesmo já abstrair banco de dados…
JPA = Especificação sob qual o Hibernate 3.0 foi construido… permite o uso de varios ORM’s… assim vc nao fica preso ao Hibernate
Só uma correção. No JPA não é EJB-QL, e sim JPA-QL. 
Eu preferiria a primeira abordagem. Mantenha as constantes com o SQL no repositório ao qual ele se refere.
Se não quer poluir suas classes com código SQL, prefira colocar em um properties, como já foi sugerido pelo Rodrigo Carvalho.
Se for possível, dê uma olhada em JPA ou Hibernate.
Desde que você não anote o seu bean persistente com 20 named querys, tá bom! 
Eu acho que o ideal é manter no próprio repositório em constantes, ou num properties melhor ainda, como bem disse o Tiego Senha.
Correndo o risco de misturar (acoplar) as camadas.
[quote=chun]
JPA = Especificação sob qual o Hibernate 3.0 foi construido… permite o uso de varios ORM’s… assim vc nao fica preso ao Hibernate[/quote]
Não inverta as coisas. JPA foi fortemente baseado no modelo do Hibernate, não o contrário. Além disso, não vejo muitas vantagens reais em se usar JPA sobre Hibernate. Ninguém fica mudando o persistence engine a todo momento, logo, se você usa Toplink/Kodo/Hibernate no começo do seu projeto, provavelmente é certo q você vá fazer deploy usando o persistence engine inicial; logo, a tal independência de persistence engine é falácia. Além disso, JPA não tem Criteria API! 
[quote=Daniel Quirino Oliveira]
Não inverta as coisas. JPA foi fortemente baseado no modelo do Hibernate, não o contrário. Além disso, não vejo muitas vantagens reais em se usar JPA sobre Hibernate. Ninguém fica mudando o persistence engine a todo momento, logo, se você usa Toplink/Kodo/Hibernate no começo do seu projeto, provavelmente é certo q você vá fazer deploy usando o persistence engine inicial; logo, a tal independência de persistence engine é falácia. Além disso, JPA não tem Criteria API! :([/quote]
Ainda não vi uma alma que tenha tido coragem de trocar de um pra outro
E cada um tem os seus próprios bugs, essa história de que “todos rodam igual” é lenda.
Na verdade, usar JPA com implementação Hibernate pode - e deve - ter até mais bugs, porque junta os bugs do Hibernate core com os do entity manager.