DAO no EJB3 ou EJB como DAO?

Programação Java
#1

Pessoal

Estou desenvolvendo uma aplicação, utilizando EJB 3 e JPA, onde projetei da seguinte forma:

Os Servlets acessam os EJB’s, que é onde está a lógica da aplicação. Dentro do EJB, eu pego a referência do EntityManager, através de injeção de dependência.

Para cada entidade, eu criei uma interface DAO e uma classe DAO que implementa esta interface (a interface é para possibilitar outras implementações do DAO).

Tenho também uma classe abstrata GenericDAO que é estendida pelas classes DAO de cada entidade.

Tenho também uma classe DAOFactory, que me retorna cada classe DAO que eu quiser. Antes disso, passo a referência do EntityManager à ela, para que todos os DAO’s usem o mesmo EntityManager.

Hoje estava lendo na revista Mundo Java deste mês, no tópico “Aprendendo Padrões Java EE com uma História Interativa” (excelente tópico, por sinal), onde é apresentada uma arquitetura onde a lógica da aplicação está nos EJB’s e os DAO’s são outros EJB’s. Desta forma, um EJB acessa outro (que é o DAO) e lá que está todo o acesso ao banco de dados.

Achei bem interessante esta solução e bem mais simples do que a que eu uso.

Gostaria de saber a opinião de vocês a respeito. Qual destas soluções gostam mais, qual considera melhor, por que, pontos positivos ou negativos de cada uma… enfim, gostaria de saber a opinião de vocês sobre estes casos. Ou mesmo se tiverem alguma outra arquitetura para sugerir, acho que seria bastante interessante.

Enfim, o que vocês acham?

Obrigado

#2

Cara, na minha opinião quando usa-se JPA a criação de DAOs passa a ser desnecessária, uma vez que o próprio EntityManager acaba tomando esse papel.

#3

[quote=Tchello] Cara, na minha opinião quando usa-se JPA a criação de DAOs passa a ser desnecessária, uma vez que o próprio EntityManager acaba tomando esse papel.
[/quote]

Eu pensei nisto, mas criei os DAO’s pra realmente separar a lógica da aplicação do acesso aos dados.

Na classe DAO eu acesso o banco, faço as operações que eu quiser e retorno o objeto pronto para ser utilizado na classe com a lógica…

#4

Saquei, faz sentido.
Li aqui no GUJ que pra JPA repository seria uma solução melhorzinha, mas não sei se confere e também não conheço quase nada desse padrão.
Da uma olhada aqui:
http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

#5

DAO como EJB3, sem sombra de dúvida! É mais simples, e não tem e criar classes burocráticas como o DAOFactory.

#6

Bom dia,

Mas EntityManager não é jà um DAO Generico ?

O Design Pattern DAO … muito complicado inutilemente !

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Abraços

#7

[quote=JxtaNode]Bom dia,

Mas EntityManager não é jà um DAO Generico ?

O Design Pattern DAO … muito complicado inutilemente !

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Abraços[/quote]

Vejo em vários lugares o pessoal falando nisso. Mas imagine o seguinte caso:

Você tem um objeto que tem relação one-to-many com outros 8 objetos. Logo, este objeto tem 8 coleções de outros objetos. Porém, estas coleções nunca serão usadas juntas. Sempre será usada apenas uma isolada, dependendo do caso. Neste caso, por razões de performance, é melhor que estas coleções sejam todas Lazy Loading, para não carregar milhares de objetos desnecessáriamente. Sabendo disso, sempre que este objeto for carregado, as coleções necessárias tem que ser inicializadas posteriormente, antes de serem acessadas.

Neste caso, EU, particularmente, não acho legal deixar na mesma classe, a lógica da aplicação junto com a inicialização dos objetos e coleções. Isto vai contra a separação de responsabilidades, que todos os livros de Design Patterns fala…

Então, neste caso, eu acho melhor criar um DAO, que carrega o objeto e inicializa suas coleções, trazendo o objeto pronto para ser usado na camada da lógica de negócio…

O que acha?

#8

[quote=diegogmarques]Pessoal

Estou desenvolvendo uma aplicação, utilizando EJB 3 e JPA, onde projetei da seguinte forma:

(…)
Enfim, o que vocês acham?
[/quote]

EJB 3 não necessita de mapeadores de ORM esse é o papel dp JPA através do EntityManager.
EJB 3 utiliza padrões de projeto difernetes que EJB <3 . Entre eles o DomainStore (que é o padrão que EntityManager implementa).
DAO é um padrão deprecated em EJB3. Isso que fique bem claro para vc e para todos.

Utilizar DAO, GenericDAO, DAOFactory são práticas arcaicas em EJB3.

Em EJB 3 e em qualquer aquitetura orientada ao dominio vc precisa de um objeto que centralize as pesquisas que serão feitas com a tecnologia ORM. Este objeto é chamado pelas outras classes que são proibidas de implementar qualquer tipo de querie.
Estas classes que concentram esta responsabilidade são chamados Repositorios e não são DAOs.

#9