xhtml -> jsfBean -> VendasEJBRepositoryManagerBusinessXuxaFezPorno(sei lá o que vc chama o cara que tem a logica de negócio) -> DAO -> JPA -> DataBase

é que o seu VendasEJBRepositoryManagerBusinessXuxaFezPorno consegue manipular as relaçoes entre as entities e as mudanças nos comportamentos dos objetos ‘quase’ como se estivessemos brincando num metodo main estupido.

ex:

@Stateless
class VendasEJBRepositoryManagerBusinessXuxaFezPornoBean implements VendasEJBRepositoryManagerBusinessXuxaFezPorno {

@EJB
VendasDAO vendasDao;

void finalizar(Venda venda){

venda = vendaDAO.get(venda.id);// eu nao quero saber como alguem busca uma venda no database!
produtos = venda.getProdutos();//lazy load ( isso é o ‘quase’ do inicio do comentario

for (Produto p : produtos){
if (!disponivel()) throw DeuPauNaVendaExcpetion(”pau”);
}

// e por ai continua
}

boolean disponivel(Prdito p){ return blablabla}
}

eu prefiro chamar myDAO.findAlgumaCoisaNessesCriterios(); a partir do meu Repositorio do que colocar a maneira como essa alguma coisa eh achada diretamente no meu Repositorio.

Os meus Repositorios sao Homens de Negocio que nao se preocupam em como as coisas sao achadas, salvas, deletadas.

Eles simplesmente decidem QUAIS e COMO as coisas vao ser feitas.
Por isso eu ainda continuo com DAOs.

Obrigado

O arquiteto deve definir o que é palpável ou fortemente provável e não algo altamente improvável. Caso contrário “criamos Robocops que acabam ajudando velhinhas a atravessar a rua”.

Quantos sistemas que utilizam Hibernate/DAO que precisaram ser trocados por TopLink ou iBatis ou JDBC puro? É provável que não apareça nenhum.

Dito isso, ainda, vejo que JPA 1.0 não é uma especificação madura o suficiente para ser utilizada diretamente no código, como já é o Hibernate. Duas questões me vem rapidamente: não possuir definição para delete-orphan, bem como não tem API para Criteria.

O que tenho visto são sistemas de utilizando Hibernate/Session com DAO e utilizando anotações JPA para mapeamento. Ou seja, se preparando pro futuro padrão de mercado sem perder as funcionalidades presentes.

Com JPA 2.0 será diferente, pois ela atende a maior parte das funcionalidades ORM. Então acredito que o padrão DAO caia em desuso.

Ah, com relação às queries de consulta espalhadas? Basta anota-las na entidade via @NamedQuery e voilá! Tchau DAO!

O bom é que ele encapsula a complexidade de controle da sessão (exemplo simples).

Mas se eu não usasse Spring certamente gostaria de encapsular esse tipo de coisa. Vamos dizer que não desse o nome de DAO.

Imaginando um EntityManager injetado em 2 Controllers, por exemplo, e nessas 2 classes eu precisasse da mesma consulta. Acho que devo isolar isso em algum lugar!

Não concordo sair chamando tudo de DAO, a menos que realmente seja um DAO. Mas concordo em encapsular coisas pra poder reusá-las e me dá menos trabalho

O mais engraçado do povo que cria DAO de modo automático, é a repetição dos métodos. Criam um save no Entity, que chama o save do DAO, que chama o save do EntityManager. Ridículo. Isso quando basta chamar o save do EntityManager, que ao contrário do que disseram acima, JPA é sim uma abstração do modelo objeto relacional.

Acho que às vezes falta pras pessoas aprenderem um pouco com outras linguagens, como Ruby. Eu adoro Java, mas mexer com outras linguagens sempre abre a mente para soluções diferentes.

Mas só para refletir, e indo na mesma direção dos comentários do George Queiroz e Eldon: e quanto a Forte Coesão e Baixo Acoplamento? Não levando em consideração que DAO e Repository abstraem a implementação do ORM, se elas apenas abstraíssem para o Controller a camada de dados já estaria fazendo seu papel, não acha? Em equipes e projetos bem estruturados e divididos, colocar uma equipe para trabalhar com os Controllers e outra com a camada de dados, usar o DAO ou Repository já seria uma mão na roda. Mesmo em equipes pequenas, onde talvez não haja uma divisão clara das partes do projeto, no mínimo seria mais clara a divisão entre controle e dados e facilitaria a manutenção.
Concordo com você que precisamos sempre avaliar os problemas e usar os padrões que melhor os resolvam. Mas a ideia desse post de que usando JPA elimina a necessidade de camadas de dados é, no mínimo, arriscada.
Meus 2 centavos.

Assim sendo, eu prefiro manipular dados como uma camada separada ou como um Helper do Service. Não acho interessante incluir nos services as necessidades de manipulação de dados, digamos sobre manipulação, principalmente buscas, que envolvem *QL.

Mais sou o adepto do ActiveRecord, infelizmente no java direto não dá, mais nada melhor que esta no mundo do GORM ou algo do tipo.

[s]

Para mais informações:

http://domaindrivendesign.org/

Livro: Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover) - Eric Evans