Duvidas sobre o pattern DAO!

JavaEvangelist Membro desde: 20/01/2009 08:43:02 Mensagens: 381 Offline

Gostaria de saber se para realizar operacoes CRUD os metodos das minhas DAOs podem ser declarados como static. Tenho essa duvida pois estou com um projeto "bem pequeno" e nao terei necessidade de recorrer a heranças entre as DAOs, sendo assim, não vejo o porque continuar programando pensando nos objetos já que para mim é mais interessante entender os metodos como pertencentes a classe e nao ao objeto, consequentemente, declara-los como static! Resumindo: gostaria que minhas DAOs se parecessem como classes utilitarias.

Obrigado.

Sinceramente, se o projeto for pequeno mesmo, acho que nem de DAO você precisa.

JavaEvangelist Membro desde: 20/01/2009 08:43:02 Mensagens: 381 Offline

Entao cara, mas eu posso ou nao declarar meu metodos como static?? Isso rompe com a definição do pattern DAO?

Você não deveria se importar com isso cara, use o que for mais adequado ao seu projeto. Ficar nessa neura de seguir ou não seguir os padrões ao pé da letra atrapalham muito as tomadas de decisão.

Mas já que isso é tão importante, faça-se a seguinte pergunta: qual a função do DAO? Depois faça a próxima pergunta: se eu tornar os métodos estáticos, meu DAO vai deixar de desempenhar a função que determinei na pergunta anterior?

Detalhes de implementação de um padrão não deveriam ser mais importantes que o conceito. A gangue dos quatro ilustrou o uso dos padrões de projeto com uma das linguagens mainstream da época - C++ - que não possuía o conceito de interfaces, apenas de classes abstratas. A literatura atual ilustra exemplos em Java e em C# de utilização de padrões que usam interfaces ao invés de classes abstratas. Aí eu pergunto: um Strategy que usa interfaces ou enumerations deixou de ser um Strategy só porque a definição tomada como referência utilizava classes abstratas?

Resumindo: se você vê que é o melhor - e não há ninguém melhor que você mesmo pra decidir isso - escreva seu DAO com métodos static e seja feliz.

Se vc pensar na utilizacao de um metodo static em um DAO, nao vejo problemas ao usar. E é umas das formas mais adequadas de criar os metodos em seu DAO.
Mas pense um pocuo tb no que o tnaires disse.

[ ]s,

JavaEvangelist Membro desde: 02/05/2006 15:30:50 Mensagens: 304 Offline

Bem eu não costumo usar métodos estaticos nos meu DAOs, e também não criu várias quantidade de DAOs para cada objeto de négocio, tais como, ClienteDAO, ProdutoDAO. etc.... Eu tenho um DAO generico com diversos métodos.

eu tenho uma classe abstrata chamada SimpleDAO e uma classe concreta chamada HibernateDAO. Durante todo meu projeto utilizo essa classe generica caso eu precisar de algum recurso especifico eu faço uma composição de classe ao inves de herança.

Abraços

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

Vini Fernandes wrote: Entao cara, mas eu posso ou nao declarar meu metodos como static?? Isso rompe com a definição do pattern DAO?

Sim!!!!!!!
Se vc está pensando em usar métodos estáticos vc ainda nem sabe o que é um DAO.

Um DAO é um objeto, logo, não pode feito com métodos estáticos.

Quanto é que vocês vão entender que não existe essa historia de "projeto pequeno" ?
Acha que porque o projeto é "pequeno" tem o direito a fazer cambiarra ? Não!

E projeto nunca são pequenos. Eles começam pequenos. Nunca ouviu falar em evoluir o software?

Pense grande e use os padrões como deve ser. Se não sabe usar os padrões, aprenda ; ou então não os use.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

mateusprado wrote:Se vc pensar na utilizacao de um metodo static em um DAO, nao vejo problemas ao usar. E é umas das formas mais adequadas de criar os metodos em seu DAO.

??? o quê ?? Uma das formas mais adquadas ? De onde raios saiu isso ? Se existem formas desadequadas essa ganha de longe de todas as outras.

O DAO para começo de conversa é um serviço definido por uma interface! não ha como colocar métodos estáticos em interfaces. Apenas isso já deveria servir de pista para concluir que DAOs não se definem com métodos estáticos!

Aliás métodos estáticos não devem ser usados. É o tipo de coisa que apenas os profissionais podem usar , do tipo "não faça isto em casa". Eles são perigosos e não são OO. Isso é outra pista para concluir que DAOs não se definem com métodos estáticos.

DAOs não se definem com métodos estáticos.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

paulofafism wrote:
eu tenho uma classe abstrata chamada SimpleDAO e uma classe concreta chamada HibernateDAO.

Porquê em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Será assim tão difícil entender que se o Hibernate é usado não ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem não acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!

Não se enganem. Isso só cria um monte de interfaces e classes a mais no projeto. Totalmente desnecessárias.

Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. De quem é a culpa do uso do DAO estar tão enraizado nas más práticas de programação atuais ?

http://books.google.com.br/books?id=1dx34EMVyi8C&dq=dao+patterns+martin+fowler&printsec=frontcover&source=bl&ots=1v_wl3TK9H&sig=QU6UjNpiMX3lpTgT4_bb5pFsRf8&hl=pt-BR&ei=kHwHSp_MLIeJtgfGv_WRBw&sa=X&oi=book_result&ct=result&resnum=1#PPP1,M1

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

JavaEvangelist Membro desde: 02/05/2006 15:30:50 Mensagens: 304 Offline

Porquê em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Será assim tão difícil entender que se o Hibernate é usado não ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem não acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!

Ai que você se engana meu amigo. Logico que da sim para utilizar outro DAO, tanto Hibernate, JPA ou JDBC e eu fiz a mesma coisa que vc fez implementei um DAO usando JDBC e outro usando JPA, para testar a flexibilidade da aplicação caso eu mudasse de tecnologia. E funcionou perfeitamente e oolha que minha classe DAO tem diversos métodos. Eu não saio instânciando meus objeto diretamente em minha aplicação:

Ao invés disso tenho uma classe Factory

A classe ApplicationContext e a classe onde da inicio ao meu sistema startando as configurações principais. basta so eu alterar essa classe e pronto. Posso alterar para outro contexto de aplicação usando DAO, JPA ou JDBC.
Basta apenas usar a classe SimpleDAO que é abstrata.

Não se enganem. Isso só cria um monte de interfaces e classes a mais no projeto. Totalmente desnecessárias.

Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. De quem é a culpa do uso do DAO estar tão enraizado nas más práticas de programação atuais ?

Monta de interfaces? Nãoo é para tanto. Para que vou criar uma interface chamada ClienteDAO, ProdutoDAO, ForncedorDAO, Ai depois você vem criando classes concretas para cada interface e por ai vai.... Isso sim não tem necessidade de criar, falta de tempo tremenda.

Sr. Vini Fernandes,

Utilizar métodos estaticos em DAOs não é uma boa idéia.

E realmente, como já disseram antes, é melhor pensar que o software será grande um dia. O software "pequeno" é apenas uma chance de vc ter o controle e uma visbilidade maior sobre o que está sendo feito; isto é bom porque vc pode ver / manipular os detalhes da tecnologia com maior facilidade.

Normalmente as pessoas começam a se interessar pelos métodos estaticos pelo fato de vc poder submeter execuções a partir de qualquer lugar do software; complicou um pouco o fluxo a pessoa logo já escreve MeuQueridoDao.arrumaTudoAi() e pronto.
Não sei se esse é o seu caso, se for saiba que isso causa desestruturação no software fazendo com a aplicação da OO seja muito fraca.

flws

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

paulofafism wrote:

Porquê em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Será assim tão difícil entender que se o Hibernate é usado não ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem não acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!

Ai que você se engana meu amigo. Logico que da sim para utilizar outro DAO, tanto Hibernate, JPA ou JDBC e eu fiz a mesma coisa que vc fez implementei um DAO usando JDBC e outro usando JPA, para testar a flexibilidade da aplicação caso eu mudasse de tecnologia. E funcionou perfeitamente e oolha que minha classe DAO tem diversos métodos. Eu não saio instânciando meus objeto diretamente em minha aplicação:

SimpleDAO dao = new HibernateDAO();

Ao invés disso tenho uma classe Factory

SimpleDAO dao = DAOFactory.getDAO(AplicationContext.getContext());

A classe ApplicationContext e a classe onde da inicio ao meu sistema startando as configurações principais. basta so eu alterar essa classe e pronto. Posso alterar para outro contexto de aplicação usando DAO, JPA ou JDBC.
Basta apenas usar a classe SimpleDAO que é abstrata.

Blz. E como vc trabalha com transações? acaso os seus DAOs abrem transações ou vc tem algum outro objeto que controla isso ?
E como vc substitui o uso de Open Session in View ?

sergiotaborda wrote:
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO.

Tenta mockar a API do Hibernate ou do JPA para você ver como é excelente a sua decisão arquitetural de não usar DAOs.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

Rubem Azenha wrote:

sergiotaborda wrote:
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO.

Tenta mockar a API do Hibernate ou do JPA para você ver como é excelente a sua decisão arquitetural de não usar DAOs.

?

Em uma arquitetura sã vc tem serviços que invocar métodos em repositorios.
Os repositorios criam as pesquisas e as executam. Se vc usa o hibernate ou o JPA vc invoca-os directamente de dentro do repositorio.
O repositorio não é plugável, não é flexivel, não é genérico e depende fortemente do dominio do sistema onde é usado.

O DAO por outro lado é plugável, é flexivel, é genérico e não depende do dominio onde o sistema é usado.

É muito simples não usar o DAO, sobretudo quando usa o Hibernate ou o JPA ( que são DomainStores).

Agora vc pode argumentar que os "daos" que o povo usa por ai são na realdiade repositorios. Isso não é verdade. Não respeitam o mesmo padrão.
É como dizer que um objeto apenas com métodos estáticos é um DAO só porque ele se chama xxxDAO. Ou que um factory é um singleton porque se chama "xxxxxSingleton". Isto é um argumento absurdo.
A comparação têm que ser feita com base no padrão. O padrão DAO é um subtipo do Padrão Service. Existe a necessidade de ter um contrato separado da implementação. Isso faz sentido porque o DAO é flexivel e plugável. Para um Repositorio isso não faz qualquer sentido já que ele não é um serviço.

Notícias, artigos e o maior fórum brasileiro sobre Java