A parte que costuma dar mais problemas é busca, então em vez de definir a métodos com critérios explícitos, utilizando uma abstração semelhante a Criteria do Hibernate, por exemplo, seria possivel transferir para a implementação do DAO boa parte da decisão de como recuperar as informações.

Porém, como no caso dos recursos do Hibernate, como o lazy-loading e flush-on-commit, esses sim podem ser evitados, mas devemos avaliar muito bem antes de decidir por não usar tais recursos, uma vez que eles são muito úteis e que muito raramente alterar a forma de persistência de um sistema será uma realidade.

já trabalhei em um projeto onde a arquitetura usava DAOs para abstrair a persistência. No caso, a promessa era a de haver uma implementação específica para o banco de dados hierárquico e, futuramente, ser possível trocá-la implementando uma relacional. Eu me questionava se isso faria sentido uma vez que todo o projeto era “otimizado” para extrair vantagens do banco hierárquico.

Minha pergunta é: há alguma solução, mesmo sem utilizar DAOs?

Abs.

Concordo com você.. mas me lembro que antigamente(antes de o hibernate ser famoso) muito material na internet nos fazia acreditar que o DAO servia para abstrair a implementação de SGBD(quase não se levava em consideração formas de persistência alternativas como ldap ou arquivo texto), tanto que eram utilizadas aquelas fabricas que nos retornavam aqueles OracleDAOImpl ou SqlServerDAOImpl nos exemplos clássicos de DAO que achavamos no google.

Na verdade muita gente se deixou levar por esse mito de esconder a implementação, parcialmente verdadeiro, já que na verdade poderia esconder a implementação desde que as implementações todas fossem JDBC..

Como você disse, DAO abstrai o mecanismo de persistencia mas não suas capacidades..