J2EE - DAO pattern

adolfo_eloy:

Boa madrugada pessoal.

Estou estudando o padrão J2EE DAO,
e tenho percebido uma grande quantidade de classes necessárias
as vezes para abstrair e implementar funcionalidades de uma
única entidade.

Tomando como base o exemplo da página da sun:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

temos que criar 5 classes somente para tratar de Customer?

Alguém conhece alguma outra fonte na web com mais exemplos
para que eu possa entender melhor este padrão?

Obrigado.

Na boa galera , tá na hora de começar a usar a busca ao lado, tem zilhões de tópicos sobre o Pattern, até um tópico interessante que estava rolando sobre DAO, Repository e tudo mais.

Agora sair perguntando sem fazer uma pesquisa é soda…

Modedor, tranca ae vai

Na boa galera , tá na hora de começar a usar a busca ao lado, tem zilhões de tópicos sobre o Pattern, até um tópico interessante que estava rolando sobre DAO, Repository e tudo mais.

Agora sair perguntando sem fazer uma pesquisa é soda…

Modedor, tranca ae vai

:?

Filho, não foi somente pra você. Esse alerta foi pra todos que usam o fórum dessa forma.

Dá uma olhada na minha data de inscrição e minhas contribuições, acho que mereço um pouco mais de respeito.

Quanto à se acertar fora do fórum, nem tem o que mencionar, passei da fase de criança rebelde. O que tiver que resolver dessa forma é no Tatame, fazer um rola na esportiva :-).

Ve ai

Falow

Não entendi.

Cara olha so …
No próprio link que tu passou mostra a motivação desse pattern,.

Context
Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation.

Os exemplos de objetos que tu esta vendo alí, são apenas ilustrativos para te situar no uso dele.
O que conta para o pattern dao é o objeto DAO em sí.
Que deve fazer exatamente o que está escrito acima.

Quanto ao DAO Factory ou a interface CostumerDAO descrita, são apenas formas de abstração de seus daos, mas fazem parte de outros patterns ou motivações adversas.

Não entendi.

Data de membro, desde 2003, e contribuições técnicas aos amigos com dúvidas.

Lembrando que a maior parte delas, infelizmente foi embora na “queda” do guj, não se se você se lembra…

Muito Obrigado a todos que ajudaram.

Bem, lendo as respostas que foram dadas e me colocando em seu lugar, eu particularmente não estaria satisfeito, assim fui até o link que vc passou e li o artigo da Sun. E cheguei a conclusões e soluções interessantes que acredito serem bastante ricas e assim terei o prazer em compartilha-lha COM AQUELES QUE ASSIM QUISEREM.

Após ler todo o artigo uma consideração importante é feita na seção "Consequences"

This additional effort needs to be considered if there is sufficient justification warranting such flexibility.

Ou seja, o esforço em questão só é válido se a flexibilidade for assim exigida. Assim, em grande parte dos casos podemos ter uma arquitetura mais enxuta e que atenda aos bons padrões de projeto.

Para isto sugiro a seguinte:

[DAO_02]-----------[DAOFactory] --------- [DAO]

Ou seja um DAO genérico, responsável pelas sessões e operações comuns às entities, CRUD’s e o DAOFactory com gets para os DAOs específicos e nestes DAOs específicos você tem operações próprias de seus respectivos Entities.

Espero ter sido claro, caso contrário poste suas dúvidas e quem sabe animo fazer o Diagrama de classes tradicional ao invés deste “Class ASCII”

[]'s

como qualquer coisa que vc vai implementar, tem que considerar se o esforço vale a pena. O uso de factory eh um deles. Hoje em dia, a factory he facilemente substituida por um container de IOC, o Spring eh o mais famoso deles.

[]'s