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.
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.
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.[/quote]
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…
[quote]
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…
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 :-).
Cara olha so …
No próprio link que tu passou mostra a motivação desse pattern,.
[quote]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.[/quote]
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.
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”
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.
