Duvidas sobre o pattern DAO!

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.

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.

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

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

paulofafism:

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.

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:

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.

Rubem Azenha:

sergiotaborda:

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.

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.

leandronsp:

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.

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

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

sergiotaborda:

leandronsp:

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.

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

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

Eu tbm… nunca vi esta façanha…

sergiotaborda:

leandronsp:

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.

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

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

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

Estava indo bem até que …

Outch! Se eu tivesse um centavo por cada vez que alguem confundo repositorio com DAO, estaria rico.

Veja bem o problema. O repositorio não é um DAO, nem o DAO é um repositorio. Logo, herança ou implementação de um pelo outro é asneira.

Este erro é muito comum pela mesma razão que é muito comuma alguem fazer este erro aqui:

public class Pedido extends HashMap<Integer, ItemPedido>

ou

public class Produtos extends ArrayList<Produto>

As pessoas ainda não sabem o que é herança. A regra é simples: perfira composição a herança. Apenas e quando A é B é que a herança pode ser usada. (Herança aqui inclui o implements e o extends)

Ora da mesma forma que um Pedido não é um HashMap e sim Pedido contém um Map, também Repositorio não é um DAO, Repositorio contém um DAO.

Inverter as coisas é ainda pior. Fazer DAO extends Repositorio é do mesmo calibre que fazer HashMap extends Pedido. Pedido é do dominio, Map é de infra. infra não pode extender o dominio. O dominio não pode extender a infra. O que pode acontecer é que o dominio use a infra. Daqui a composição ao invés da herança.

Pior ainda é escrever um DAO usando JPA por baixo… JPA é orientado ao dominio. DAOs não são. Você não precisa usar a camada de DAO se usa JPA.

Por amor de Deus, pessoal, estudem a arquitetura JPA e o padrão Domain Store. É triste vos ver cometendo o mesmo erro vezes sem conta…

A partir do ponto que vc misturou tudo não só você não sabe no “mato sem cachorro” em que se está metendo como você ainda sofre do sindrome de DAO. Pelo menos vc ainda vislumbra uma diferença entre DAO e Repositório. Isso já é um bom sinal para um cura possivel.

leandronsp:

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.

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.

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

leandronsp:

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

O uso de interfaces no DAO é a forma como o padrão foi projetado originalmente. O que as interfaces com prefixo Repositório que você utilizou têm de especial que a fazem levar o nome pomposo de Padrão Repositório?

Sérgio,

Obrigado pelas críticas. Todas são mto bem-vindas.
A idéia do DAO nesta aplicação é justamente ele fazer os CRUDS. E o DAOFactory iniciar transações do JPA, comitar, etc.

Obviamente, nota-se na classe DAO os métodos que fazem os trabalhos de persistência utilizarem o EntityManager. Ficou uma coisa meio óbvia, e cheguei a pensar: “pra quê ter DAO, se tudo isso parece feijão com arroz ‘duas vezes’?”.

Entendi oq vc quis dizer, e pesquisando melhor em foruns, no seu blog inclusive, em links recomendados, percebi que o EntityManager do JPA e o Session do Hibernate poderiam ser os “DAO´s” da aplicação (certo?). No meu caso, como utilizo o Repository, eu injetaria o EntityManager nas minhas classes de negócio do Repository? Algo como:

class RepositorioCRUD () {
   private EntityManager em;

   // construtor que recebe o EntityManager
   public RepositorioCRUD () {
      em = JPAUtil.getManager();
   }

   public void adicionar (Object o) {
      this.em.persist(o);
   }

   // outros metodos de persistencia omitidos e getters
}

Se for dessa forma, não fica parecendo um DAO, só que com outro nome?
Obrigado.

leandronsp

Dá uma lida neste link http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html, nele tem esta definição data pelo autor que pode lhe ajudar.

Debasish Ghosh:

The main differences between the Repository and the DAO are that :

* The DAO is at a lower level of abstraction than the Repository and can contain plumbing codes to pull out data from the database. We have one DAO per database table, but one repository per domain type or aggregate.

* The contracts provided by the Repository are purely "domain centric" and speak the same domain language.</blockquote>

Não deixe de ler o post do cara (Debasish Ghosh) acho que irá melhora um pouco mais o seu entendimento além de dar outras idéias.

flws

Certo!
Só lembrando que realmente o EntityManager é uma implementação do padrão DomainStore.
O Session do Hibernate é uma implementação do padrão UnitOfWork

Sim. Exactamente.

Não. Isso é um erro comum. Se X e Y parecem ter a mesma interface então X é Y. não!
Para X ser Y ele precisa ter não apenas a mesma interface como a mesma responsabilidade.

DAOs e Repositorios têm responsabilidades diferentes , portanto é impossivel confundi-los.

fantomas:

leandronsp

Dá uma lida neste link http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html, nele tem esta definição data pelo autor que pode lhe ajudar.

valeu fantomas…vou trabalhar mais essas técnicas ensinadas

hum… parece que ficou mais clara essa divisão de responsabilidades. Creio que esta aplicação não foge mto doq vcs estão colocando, porém com algumas ressalvas, tais como utilizar mais composição (ao invés de herança) e fazer meu domínio enxergar a interface do repositorio apenas, e não um “dao”. Realmente pra essas coisas eu não tinha me atentando mto. Vou estudar mais o material do Evans - DDD.

O lance aqui então é: a interface do meu repositorio deve ser como um “contrato”, numa linguagem fácil para fazer parte do domínio.
A implementação do meu repositorio “contém” a infra-estrutura para persistência, neste caso o JPA.

Criar repositorio para DAOs é criar abstrações em cima de abstrações, totalmente desnecessário IMO.

mochuara:

Criar repositorio para DAOs é criar abstrações em cima de abstrações, totalmente desnecessário IMO.

Isso seria verdade ser existisse uma relação 1-1. Como a relação é 1-N então isso não se aplica.

Uma entidade X tem um repositorio. Mas X é um agregado de Y, Z , … etc… logo o repositorio de X utiliza o DAO de Y, Z, etc…

A aplicação vê apenas um repositorio e o X. Mas por baixo dos panos muitas entidades estão implicitas e muitos DAOs.
Contudo, hoje em dia o DAO é desnecessário. Utilizando qualquer domain Store voce tem uma relação N-1. Vários repositorios chamam o mesmo DomainStore (porque ele não é por entidade e sim por dominio).

Veja-se como se vir, devido a que nunca existe uma relação 1-1 entre repositorios e DAOs / DomainStore , a abstração não é desnecessária.