Duvidas sobre o pattern DAO!

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.

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,

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

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.

[quote=mateusprado]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.
[/quote]

??? 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.

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

[quote]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!
[/quote]

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.

[quote]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 ?[/quote]

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

[quote=paulofafism][quote]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!
[/quote]

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.
[/quote]

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 ?

[quote=sergiotaborda]
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. [/quote]

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

[quote=Rubem Azenha][quote=sergiotaborda]
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. [/quote]

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

?

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.

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
A programação com repositorio, se bem utilizada, fica bem facil de ser compreendida, podendo permitir vc criar varios metodos de consulta e dar manutenção.

[quote=leandronsp][quote=sergiotaborda]
?

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.
[/quote]

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
[/quote]

Ser independente do domínio e da persistência é impossível. Essa afirmação precisa de de um exemplo que a comprove.

[quote=sergiotaborda][quote=leandronsp][quote=sergiotaborda]
?

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.
[/quote]

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
[/quote]

Ser independente do domínio e da persistência é impossível. Essa afirmação precisa de de um exemplo que a comprove. [/quote]

Eu tbm… nunca vi esta façanha…

[quote=sergiotaborda][quote=leandronsp][quote=sergiotaborda]
?

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.
[/quote]

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
[/quote]

Ser independente do domínio e da persistência é impossível. Essa afirmação precisa de de um exemplo que a comprove. [/quote]

Além de ser impossível, oq vc ganha(ria) com tanta flexibilidade?
Não vejo utilidade de se criar o sistema mais independente do mundo, tão independente que ele nem precisa saber o domínio dele. Basta vc pensar no seu problema perto dele, e ele resolve =/

Desculpem, creio que me equivoquei em dizer que o repository fica independente do dominio. Ele faz parte do dominio. Qdo desenvolvo o dominio, eu tbm crio os repositorios.
Mas ainda entendo que ele é independente da persistencia. Vou tentar demonstrar:

public interface RepositorioInterface<T> () {
   public void adicionar(T objeto);
   public void remover(T objeto);
   public List<T> listarTodos();
}

Um factory Interface para definir os repositorios mais especificos:

public interface RepositorioFactoryInterface {
   public void beginTransaction();
    public void commit();
    public void flushAndClear();    
    public void rollback();
    public void close();
   public ArquivoRepositorioInterface getArquivoRepositorio(); // aqui é definido o método para retornar um ArquivoRepositorio
}

Um repositorio interface mais especifico, que extende o RepositorioInterface:

public interface ArquivoRepositorioInterface extends RepositorioInterface<Arquivo> {
   public List<Arquivo> getArquivosDestaque();
}

Até agora, minhas interfaces de repositorio foram independentes da persistencia.
A partir de agora, a implementação do Dao (infra-estrutura para persistência):

public class ArquivoRepositorioDao extends Dao<Arquivo> implements	ArquivoRepositorioInterface {
   public ArquivoRepositorioDao(EntityManager em, RepositorioFactoryInterface factory) {
		super(em, Arquivo.class, factory);
   }

   public List<Arquivo> getArquivosDestaque() {
		// queries para retornar o desejado
   }

Neste caso estou utilizando a persistencia com JPA. Meu DaoFactory é implementado da seguinte forma:

public class DaoFactory implements RepositorioFactoryInterface {
   protected final EntityManager em;
   private EntityTransaction transaction;

   public DaoFactory() {
        em = JPAUtil.getEntityManager();
    }

    public void beginTransaction() {
        this.transaction = em.getTransaction();
        this.transaction.begin();
    }

    // demais metodos a serem implementados da interface
}

Na aplicação o objeto do tipo RepositorioFactoryInterface faz os trabalhos de persistência:

RepositorioFactoryInterface factory = new DaoFactory();
List<Arquivo> arquivos = factory.getArquivoRepositorio().getArquivosDestaque();

Não sei se ficou claro, mas eu entendo que mesmo que eu altere minha forma de persistência (no caso, trocar o JPA por qq outra coisa), não afeta as lógicas de persistência no repositório (eu só alteraria meu Dao).