Síndrome de DAO

É com pesar que assisto à expansão desta síndrome que atormenta os desenvolvedores Java de hoje: a necessidade mórbida de colocar DAO em toda a arquitetura Java e de utilizar objetos com nomes afixados com “DAO”, mesmo quando eles não seguem o padrão DAO. São estes os sintomas mais comuns da síndrome. Observe-se que não bastando confundir a arquitetura com objetos inúteis, ainda por cima lhes são atribuídos os nomes errados.

Esta síndrome é extremamente contagiosa e de difícil erradicação. Uma vez contagiado, o indivíduo perde a sua capacidade de análise e de pensar por si próprio, lançando-se na citação senil de velhos testamentos e personalidades. A falta de capacidade de análise também suprime o entendimento de novos padrões, novas visões e até mesmo de evoluções naturais de desenhos e arquiteturas recorrentes, ou seja, a cura. O contagiado não mais aceita o senso comum que deu origem ao padrão em primeiro lugar, nem consegue entender as circunstâncias e objetivos da sua invenção.

Aquele que é afetado pela Síndrome de DAO torna-se incapaz de pensar em formas de persistência que não sejam mediadas ou encapsuladas num objeto afixado com “DAO” sob a desculpa que a palavra divina, entregue a ele pelos velhos testamentos, dita que desta forma irá irradicar a dependência da tecnologia de persistência e poderá comunicar-se com qualquer outra tecnologia que escolher no futuro. Note-se que o contagiado faz isto ignorando os reais propósitos e circunstâncias que apelam à utilização do DAO visto que o efeito supressor da síndrome impede o contagiado de entender a falácia que prescreve, ao mesmo tempo que o lança num estado psicotrópico em que a lógica não mais existe e padrões são transformados em anti-padrões.

O contágio ocorre fundamentalmente pela falta de vacinação contra a perda de memória e raciocínio lógico, associada à falta de informação atualizada. A exposição aos agentes de contágio presentes em cursinhos de programação, blogs, grupos de discussão e, sobretudo em projetos desenvolvidos pelos infectados, deve ser evitada. Tais locais devem ser isolados sob quarentena, devendo o tratamento ser iniciado imediatamente sob risco de morte encefálica dos afetados.

A cura é, contudo, difícil e demorada e o melhor remédio é realmente a vacinação.

Estirpes mais perigosas foram recentemente encontradas, nas quais o DAO se conecta a um Domain Store, afetando o seu sistema central. A mais virulenta delas está comumente associada ao Hibernate Domain Storus, um Domain Store vulgar cuja proliferação pode ter sido a causa da mutação do agente da síndrome. Exterminar estas estirpes é, com certeza, o desafio da proxima década, mas não podemos desistir.

Temos que continuar lutando para erradicar o Sindrome de DAO de uma vez por todas.

Ajude quem sofre com a Síndrome de DAO.

Anúncios

13 opiniões sobre “Síndrome de DAO”

  1. :)))))

    Faltou no final um exemplo de DAO Genérico usando Hibernate. Este mesmo poderia ser utilizado como teste para detecção da sindrome, seria assim: O programador olha seu exemplo, vai no código de seus programas e verifica se tem algo semelhante, em caso afirmativo tá detectado a sindrome!!!

  2. Como ainda não inventaram formas seguras de conter esse espécime (DAO com Hibernate) correria o risco de infectar este blog com a síndrome. Prefiro não ajudar à sua proliferação 😉

  3. Oi Sérgio,

    Concordo que o DAO não é lá o melhor dos padrões, e existem outras alternativas como ActiveRecord, Repositories, etc. E claro sobre a obrigatoriedade do mesmo. Mas porque “DAO” é tão nocivo assim?

  4. O DAO é um ótimo padrão para aquilo que ele tenta resolver. O problema que afeta as pessoas com Síndrome de DAO é achar que todos os objetos são DAO. Repositórios, Serviços, Domain Store, tudo é reduzido à mesma coisa. Estas pessoas usam o prefixo DAO indiscriminadamente e afixam-o em qualquer objeto sem pudor em reconhecer se as responsabilidades do objeto são realmente as de um DAO. Não é o DAO que é nocivo. É a Síndrome de DAO que é nocivo. A incapacidade de pensar além do padrão DAO, a incapacidade de reconhecer a diferença entre esses objetos e outros. Enfim, a incapacidade de evoluir no mundo do Design Patterns

  5. Fala cara,

    Achei o post engraçado, existe muita gente por aí mesmo que usa os padrões indiscriminadamente sem entender exatamente o propósito e a função.

    Mas acho que faltou colocar no post o conteúdo desse seu comentário de resposta ao João Paulo. A princípio achei que você era contra DAO, mas sua opinião ficou muito mais clara depois que li o comentário.

  6. Opa,

    Parabéns pelo blog! Encontrei por acaso navegando nos fórums do guj e gostei muito da clareza e o jeito que você escreve os textos.

    Sobre o post, não sei porque mas enquanto eu lia me veio na cabeça a imagem do grande Enéias carneiro discursando… hehehe

    abraço

  7. Plagiando o Cabelo do Viva ao Linux, este tinha uma quote dizendo: “Use a força, leia os Fontes”. Acredito que o mesmo acontece para a utilização de Patterns, o povo vê simplesmente vê a idéia, como no caso o maravilhoso esquema de extender uma classe com métodos que acessam o banco e facilitam a vida do mesmo e acabam abraçando a causa do DAO tornando tudo isto que é desenvolvido como “padrão”!
    Legal teu blog.

    1. Como ainda não inventaram formas seguras de conter esse espécime (DAO com Hibernate) correria o risco de infectar este blog com a síndrome. Prefiro não ajudar à sua proliferação

      Pergunto,

      Não existe o meio seguro ou o DAO com Hibernate, ou o proposito que iria combinar o melhor design pattern ao DAO não é esclarecido ao seu melhor emprego, o que tanto na sua otica iria caracterizar a Sindrome de DAO, é o que é objeto ao domainStore, ou a outra funcionalidade desconhecida frente a metodologia sobre FrameWorks como o Hibernate ou JPA.

      Abraçoss

      1. Se bem entendi você quer saber o que se usa em alternativa ao DAO com Hibernate. A resposta é simples. Vc usa o Hibernate sem o DAO. Vc usa o Hibernate diretamente de dentro do Repositorio.
        Tradicionalmente temos : qq classe do sistema –acessa–> DAO –acessa–> Hibernate
        O proponho é : qq classe do sistema –acessa–>Repositorio — acessa –> Hibernate

        A questão que surge é : Mas não é isso a mesma coisa ? Esse objeto do meio não é o mesmo ? Não é.
        Não é porque não tem a mesma responsabilidade. E não ser capaz de enxergar isso é que caracteriza o Sindrome de DAO.

      2. Então vem a questão,

        Em uma ocasião você afirmou que o DAO é para acessar sistema legado somente, mas então fica a questão tirar essa responsabilidade do DAO para o sistema acessar somente o repositorio e acessar o Hibernate implica em algo tradicionamente no deveria se usar o DAO, que já vem utilizando em diversos sistemas legados, outra coisa poderiamos indo eliminando os DAOs desses sistema isso não impactaria em interferir em alguma especifificação ou é mesmo um caso de design pattern que esteja já tratando dessa responsabilidade, em vista que o repositorio seria um objeto de infra.

      3. Bom, Sergio

        Pode ser que eu esteja fazendo um mix de conceitos ou me embaraçando para colocar a pergunta de forma mais inteligivel possivel, estava relendo a frase abaixo, me desculpe a insistencia.

        “Não é porque não tem a mesma responsabilidade. E não ser capaz de enxergar isso é que caracteriza o Sindrome de DAO.”

        Pergunto,

        Então tem a mesma responsabilidade nas participam de dominios diferentes, para o uso do DAO uma versão do (Hibernate legado) pra uma outro FrameWork JPA já atende um Dominio orientado ao repositorio, já que o Domain Model se encaixa melhor nesse conceito.

        Abraçosss ; )

      4. Vamos deixar uma coisa clara. Domínio não é um conceito novo. Sempre existiu. As pessoas falam mais dele agora por causa do DDD, mas domínio é de OO. Domínio é o nome da camada onde ficam os objetos que contêm regras especificas para o negocio/problema que o software pretende ajudar/resolver. É a parte do sistema que não é reaproveitável entre empresas diferentes que queiram usar um software semelhante. O domínio se liga a dados pelo domainstore/repositorio e se liga à apresentação pelos serviços. ( apresentação não é necessáriamente UI, pode ser um webservice, por exemplo). Um dos componentes do domínio são as entidades.
        Lembra do modelo E-R (Entidade-Relacionamento). Entidade tb não é um conceito novo.

        DAO é um padrão para desacoplar o acesso a dados. Dados. Não entidades. Hibernate trabalha com entidades. Hibernate não é um DAO nem pode ser usado dentro de um DAO. DAO acessa dados. Hibernate acessa entidades. JPA tb acessa entidades.

        Repositorio manipula entidades, não dados. DAO e repositorio sem diferentes por isto:

        Responsabilidade : DAO = CRUD de dados armazeandos com tecnologias especificas. Respositorio = Pesquisa (só o R de CRUD) de entidades armazenadas no DomainStore. O que está por baixo do domainStore não importa.

        Abstração : DAO = abstrai a tecnologia de acesso aos dados. Se é na memoria ou no banco ou em arquivo , etc.. e para cada um deles as suas variantes. Memoria em lista, arvore, mapa ? banco SQLServer ou Oracle ou HSQL ou … ? arquivo xml com qual esquema ? Existe demasiadas variantes. O DAO abstrai isso de forma que vc não precisa saber qual deles está usando. Repare que tudo é sobre protocolo de dados/comunicação e tecnologias de persistencia. Os dados em si, são irrelevantes.
        Repositorio = abstrai as regras de procura de entidades. Ok, vc quer os pedidos faturados em 2008. Como se encontram esses pedidos ? fazendo a pesquisa : “procure todos os pedidos cuja data de faturamento é do ano 2008”. O repositorio traduz isto el código internamente e chama quem tiver que chamar para que as entidades certas sejam encontradas. O seu objetivo não é isolar tecnologia de persistencia , protocolos ou forma de comunicação. O seu objetivo é encapsular a criação de pesquisas.
        Quando a regra de pesquisa mudar para “procura todos os pedidos com estado “faturado” cuja data de faturamento é no ano 2008″ é muito simples. Vc vai apenas alterar 1 classe : o repositório. Alterar apenas 1 classes quando apenas 1 alteração é necessária é o objetivo de todo o design OO. É isso a base do principio de separação de responsabilidade.

        São claramente objetivos diferentes. Enxergou agora ?

      5. Boa Noite, Sergioooo !!!!

        Primeiro obrigado pelo esclarecimento, e pela excelente explicação, ficou mais claro sim !!!

        Valeuuu + um Vez,

        Abraçoss !!!!!

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

w

Connecting to %s