Síndrome de DAO

O assunto Repository X DAO já está bem batido, eu sei, mas é impressionante como isso confunde muita gente até hoje… Muitas pessoas já postaram sobre isso mas eu quero dar meus dois centavos.

Com a popularização do Domain-Driven Design ví muita gente simplesmente renomeando seus XptoDAO para XptoRepository achando que assim estariam aplicando DDD porque “chamar um objeto de Repository é mais semântico que DAO”. Esses dias no Twitter ví uma mensagem assim: “Repositório ou DAO ? Eu gosto do nome repositório porque me parece ser uma abstração mais adequada”. Vamos lá, não se trata somente de nomes diferentes para a mesma coisa.

O padrão DAO têm o objetivo de criar uma abstração da infra-estrutura de armazenamento de dados para a aplicação. Uma camada de persistência é útil porque dá a funcionalidade de armazenamento/persistência de dados sem revelar detalhes específicos da infra-estrutura por trás disso. O armazenamento pode ser feito num banco de dados, em vários bancos de dados, em um webservice, em um arquivo texto, tanto faz, mas do ponto de vista da camada de negócios que obtém esses dados, por exemplo, ela está lidando apenas com busca, alteração e gravação de objetos em algum lugar que nem importa.

Já o padrão Repository tem o objetivo de dar apoio ao domain model fornecendo persistência. Ao contrário do DAO, que é um objeto de infra-estrutura da aplicação e faz parte da camada de persistência, o Repository faz parte do domain model que é parte da camada de negócios.

Domain models (modelos de domínio) fazem sentido quando a aplicação tem regras de negócio muito complexas. Isolar as regras de negócio em um domain model torna mais fácil o trabalho de focar e lidar com essas regras complexas. Porém, para que um software possa funcionar fortemente baseado em domain model (que é a proposta de Domain-Driven Design) é necessário dentre outras coisas que haja algum componente que faça parte desse modelo e permita que se faça persistência de dados – e daí veio o Repository.

No ano passado conversei bastante com o pai do DDD – Eric Evans – sobre isso e para ele o problema é que as pessoas confundem esses dois conceitos porque realmente são bem parecidos. Na maioria dos casos você irá precisar dos dois, porque o domain model fará buscas por objetos em um Repository que por sua vez delegará para o DAO, que é quem entende como é a infra-estrutura de armazenamento de dados. Para ele também não importa se o Repositório é uma classe ou uma interface, o que importa é que os objetos do domain model deverão dempre lidar com busca e persistência de objetos usando a interface do Repository, que tem o compromisso de ser mais semântica do que a do DAO.

Tags: , , , , , ,

14 Responses to “Síndrome de DAO”

  1. Rodrigo Pinto says:

    Excelente post.
    É um assunto já batido como você disse , porém mal entendido. Tenho estudado-o bastante ultimamente e noto que as pessoas tem uma real necessidade de “reaculturamento”, em entender melhor a divisão das camadas(arquitetura). Elas se apegam a algum tipo de MVC que é ensinado onde só existe o DAO, ou então argumentam – o porque de mais uma “camada” sem necessidade – sem enteder que não existe essa tal camada.
    Parabéns, e sempre é bom bater na mesma tecla, quando ela está falhando.

  2. Bruno says:

    Show de bola Chapiewski, realmente existe um mistura grande de conceitos, o shoes um tempaço atrás publicou um artigo em revista com exemplos de repository, daos..e etc, bem bacana.
    Acredito que o que falte no livro do Evans, apesar de ser muito bom, seja mais exemplos de código.

  3. Marcelo says:

    Qual a diferenca entre Repository e Business Object?

    • @Marcelo

      Repository é isso que você leu no post, um padrão de Domain-Driven Design que esabelece um componente dentro do modelo de domínio para trabalhar com persistência de dados.

      Já o Business Object é um padrão J2EE que teoricamente serve para “evitar duplicação de regras de negócios”. Os BOs são objetos que no fundo só servem para passar objetos anêmicos de um lado pro outro (os Transfer Objects). Essa abordagem está cada vez mais em desuso e não faz sentido em DDD. Mais detalhes aqui: http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm

      [ ]s, gc

  4. Fala GC.
    Ótimo post. Conseguiu enfatizar bem que “toda a diferença está na semântica.”

    Abraço

  5. Rodrigo says:

    Excelente post (acabei de descobrir esse blog). Já adicionei no Google Reader :)

    Eu li o Applying DDD do Jimmy Nilsson mas achei meio confuso; parece um blog post de 500 páginas. Eu aproveitei bem mais o novo do Dino Esposito (http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-PRO-Developer/dp/073562609X?tag=iheartworld-20). Outra referência legal (e gratuita) é o DDD Quickly (http://www.infoq.com/minibooks/domain-driven-design-quickly)

    Sobre DAO x Repository, eu gosto de pensar em repositórios como uma forma de oferecer uma API limpa e homogênea para as camadas de cima. Mas também acho que em muitos casos pode ser exagero, aplicações simples não teriam problema nenhum em usar os bons e velhos active records e coisas do genêro. Vejo muita gente em blogs e lá no stackoverflow.com recomendando que se use repositórios em aplicação com 3 classes e 3 tabelas, meio demais né.

  6. Olá Guilherme,

    Muito bom seu post fazendo essa distinção de DAO sendo objetos de infra-estrutura e Repository sendo objetos do domínio.

    Erros como este que você citou, de renomear os DAO’s, são muito comuns, pois mesmo o Livro do Eric Evans não explica a diferença de DAO x Repositóry na prática, no código. Então fica a sugestão caso queira publicar um trecho de código ou uma modelagem, para que a gente possa entender melhor essa diferença na prática!

    []’s

  7. Acho que mais do que elucidar as diferenças entre um e outro (DAO e Repository) vale a pena descrever casos em que entraria o uso de um, de outro, ou de ambos. O tratamento “abstrato” dado no post é ótimo, porém um exemplo deixaria tudo mais claro.

    De qualquer forma, parabens pelo o trabalho. O blog é excelente.

    Abraço,
    Eduardo Amuri

  8. Marcos Urata says:

    Olá Guilherme,

    Eu acho que sou mais um dos que não entenderam a diferença prática entre um Repositório vs. DAO. Eu entendi a sua explicação qdo diz q o Reposítório faz parte do modelo de domínio, enquanto um DAO faz parte da infra-estrutura da aplicação.

    Entretanto, um DAO ja é uma abstração do mecanismo de persistência. Os exemplos de código que andei vendo as pessoas “aplicando” esse conceito de repositório foi criando exatamente essa camada adicional para abstrair o próprio DAO. Ou seja, uma abstração da abstração.

    Não consegui ver qual o real ganho dessa camada se a única coisa que esta sendo feito é criado mais um nível de indireção sem nenhum ganho concreto.

    Enfim, se tiver algum trecho de código para postar demonstrando esses conceitos e diferenças, talvez fique mais fácil para mim e para outras pessoas que ainda não conseguiram visualizar bem a vantagem e a aplicação desse conceito.

  9. Concordo totalmente com o que disse. Aliás já falei a mesma coisa no meu blog , curiosamente com o mesmo titulo >:> , lol

    http://sergiotaborda.wordpress.com/2008/06/16/sindrome-de-dao/

  10. Don says:

    Conhecidência ?
    Sei….
    Mas parabens ambos pelo bom trabalho.

Leave a Reply