Loading ...
Sorry, an error occurred while loading the content.

Re: [riojug] DAO generico vale a pena?

Expand Messages
  • Timothy High
    Entendi a necessidade de resistir a utilização de tecnologias de moda só por ser novidade, mas chamar Spring, Hibernate e Ajax de modismos é um pouco
    Message 1 of 22 , Jun 9, 2011
    View Source
    • 0 Attachment
      Entendi a necessidade de resistir a utilização de tecnologias de moda só por ser novidade, mas chamar Spring, Hibernate e Ajax de "modismos" é um pouco exagerado. Você bem que escolheu 3 tecnologias que não só se encontram em forte utilização anos após seus lançamentos tanto quanto mudaram radicalmente a forma de se criar sistemas hoje em dia:

      * Spring trouxe a prática de DI para utilização quase-obrigatória em sistemas novos, e desafiou a noção que até então era quase incontestável de que middleware é necessário
      * Hibernate foi uma solução O/RM open source tão poderoso e elegante que acabou mudando o modelo de persistência do próprio JEE
      * Sem AJAX, não teria Web 2.0: GMail, Google Docs, etc. etc.

      Entendi o sentimento: não se usa ferramenta só porque é sexy, e principalmente em sistemas de negócios. E em sistema que já tem milhões de linhas de código, vai trazer muito mais prejuízo do que ganho em introduzir novas tecnologias que serão utilizadas aleatoriamente nas partes do sistema ainda em manutenção. Por outro lado, as tecnologias acima não trouxeram apenas novas ferramentas, mas também novos conceitos de arquitetura. Vale a pena a equipe experimentar com as novidades, tanto para o aprendizado quanto para o moral da equipe (é muito chato fazer apenas manutenção nas mesmas 10 milhões de linhas de código em EJB 2.0). Tem que procurar o lugar certo para fazer essas experiências de forma sensata, sem atrapalhar a manutenção do sistema.

      Um abraço,
      Tim.

      2011/6/8 wardog1 <wardog1@...>
       

      DAO é um destes (poucos) mecanismos de programação que deu certo.

      Acredito, firmemente, que a simplificação é o único método confiável de se desenvolver código reutilizável.

      A abordagem mais simples que encontrei é a seguinte:

      1ª Parte

      1) DAO abstrato para cada tabela com as funções de insert, update, delete e de select sem joins com outras tabelas
      2) DAO concreto, para cada SGBD, com a implementação de 1)
      3) DAOFactory para instanciar 2) . É um DAOFactory por DAO abstrato.

      2ª Parte

      4) DAO abstrato para fazer consultas com joins. Este DAO deve ser organizado de acordo com regras de negócio. Ex.: DAO financeiro que precisa fazer consulta envolvendo joins com outras tabelas.
      5) DAO concreto, para cada SGBD, com a implementação de 4)
      6) DAOFactory para instanciar 5). É um DAOFactory por DAO abstrato.

      Obs. 1

      Outro aspecto importante é o uso de Facades para implementar regras de negócio. DAO deve ser utilizado somente para persistência/consulta deixando para o Facade utilizar os vários DAOFactory e consumir os serviços do DAO respectivo.

      Obs. 2

      Ao desenvolver sistemas de negócios, tenha em mente a seguinte abordagem:

      1) Nada é mais importante do que o modelo de banco de dados: é o único ativo de TI perene que sobrevive ao tempo. Dedique tempo, reflexão e persuasão para simplificá-lo ao máximo possível.

      2) Ao desenvolver seu MVC, DAO e Facade utilize ao mínimo a programação OO. A justificativa é simples: sistemas de negócios são procedurais. A linguagem OO é muito boa para desenvolver games e aplicações nais quais a programação procedural é inadequada, mas, para aplicações de negócios geralmente é um saco de tempo sem fundo.

      3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

      2011/6/7 Jean Jorge Michel <jeanjmichel@...>
       

      Boa noite pessoal.

      Queria saber dos amigos se vcs acham vantagem ter um DAO generico ao invés de DAOs para casa classe do sistema.
      Deixa eu ver se me faço entender.

      Hoje estou vendo um sistema onde TUDO é genérico. Ok, pode ser válido. Mas ai vem aquela pergunta: e o ovo, veio antes ou depois da galinha? Quando temos um DAO genérico e queremos algumas ações específicas para uma classe? Aqui foi feito um DAO para a classe X que estende o genérico e tal.... mas quase toda a classe tem sua peculiaridade, então são muitos DAOs estendendo o genérico.

      A Caelum no seu blog fala em interfaces para restringir o DAO genérico.
      Aí teremos um uma interface do DAO genérico > a implementação do DAO genérico > a Interface de restrição > o DAO que estende o genérico e implementa a interface. Ufa. Se eu vou ter isso para 30 classes eu posso economizar 30 interfaces não tendo esse DAO genérico.

      Queria o conselho, a experiência dos amigos sobre o assunto.

      Pela atenção obrigado.



      --
      Best regards,
      Jean J. Michel

      * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
      My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
      My Twitter: http://twitter.com/jeanjmichel



      --
      Att,

      Roberto Messa
      Analista/Programador Java Sênior
      21 72138181


    • wardog1
      2011/6/10 Jean Jorge Michel ... Deu sorte! Podia ser MUITO pior. O sistema podia ter Spring e Ajax ou outros experimentos tecnológicos
      Message 2 of 22 , Jun 10, 2011
      View Source
      • 0 Attachment
        2011/6/10 Jean Jorge Michel <jeanjmichel@...>
         

        JSF backing beans/managed beans: faz as validações e chama um ou vários facades
          Facade (toda a lógica. pode usar mais de um DAO)
            DAO (usa Hibernate)
              Banco


        Deu sorte! Podia ser MUITO pior. O sistema podia ter Spring e Ajax ou outros experimentos tecnológicos e humanos.
         


        Diria que me deixaram o feijão com arroz. E somente o desenho, sem uma classe implementada. Mas beleza.


        Ótimo: tens uma chance de descartar a complexidade que te deixaram e fazer simples.
         


        Depois que o desenvolvimento das classes de modelo e testes unitários terminou (testando algumas lógicas de modelo como relacionamento entre classes, repetições de dados em listas, etc) me perguntaram “e aí, DAO genérico ou não?”.

        Classes de modelo? Tremo ao ouvir isto :|
         

        Vim aqui trocar uma idéia com os mestres e me deparei com outra pi**, esses infernos de DAOs nem precisam existir!

        Tem alguma coisa errada. Se o teu sistema usa um SGBD, o uso do padrão DAO é o mais simples.


        Pelo o que eu entendi o "melhor" seria eu fazer: Já que meus pobres POJOs estão repletos de anotações por "culpa" do Hibernate, eu ao invés de usar um DAO para DAOx.save(entidade) vou fazer isso no Facade. Certo?

        É uma pena que tu tenhas que utilizar o Hibernate, pois, como tu já vistes, o Hibernate é bom para complicar e aumentar o risco do projeto.

        Quanto ao Facade, é um padrão importante que serve para encapsular as regras de negócio. O Facade deve ser ignorante em relação ao SGBD.
        Utiliza o padrão DAO e DAOFactory para manipular o SGBD e simplificar o teu projeto.
         


        Valeu a todos que responderam com seriedade. Pra mim não ofende perguntar e gosto muito de poder usufruir da sabedoria da galera para aprender cada dia mais, já que aqui na empresa não tenho esse tipo de recurso :-)

        Parabéns pela tua atitude Humilde: quanto mais Humilde, mas se aprende.
         



        --

        Best regards,
        Jean J. Michel

        * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
        My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
        My Twitter: http://twitter.com/jeanjmichel



        --
        Att,

        Roberto Messa
        Analista/Programador Java Sênior
        21 72138181
      • Gilmar Candido
        Não é flamewar, não é nem discussão. Mas de toda forma me desculpem, é claro que esta afirmação foi uma brincadeira. ... Não é flamewar, não é nem
        Message 3 of 22 , Jun 10, 2011
        View Source
        • 0 Attachment
          Não é flamewar, não é nem discussão. Mas de toda forma me desculpem, é claro que esta afirmação foi uma brincadeira.

          Em 10 de junho de 2011 15:38, Marcos Dantas <dantas.marcos@...> escreveu:
           

          Pessoal... defendam pontos de vista e não uma flamewar...
           


           
          Em 10 de junho de 2011 14:56, Gilmar Candido <gilmarcand@...> escreveu:
           

          "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir." 

          Como alguém tem coragem de escrever isto?



          Em 10 de junho de 2011 14:51, Julio Cabral <jcabral_br@...> escreveu:

           

          Prezados,

          Gostaria que me explicassem que conclusão é esta: "sistemas de negócios são procedurais."

          Em relação ao item
          3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

          99,99% dos desenvolvedores no mundo concordam que essas tecnologias agregam muito e não são tão complicadas para aprender. É só fazer certo e saber programar.

          grande abraço,

          Julio


          --- Em sex, 10/6/11, Valter Lobo - Imaginary Software System <valter.imaginary@...> escreveu:

          De: Valter Lobo - Imaginary Software System <valter.imaginary@...>
          Assunto: Re: [riojug] DAO generico vale a pena?
          Para: riojug@yahoogroups.com
          Data: Sexta-feira, 10 de Junho de 2011, 9:08

           

          Gostei desta afirmação :
          " Sistemas de negócios são procedurais."  e uma conclusão que tambem cheguei depois de 10 anos de experiência.

          isto tambem e muito valido :
          "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir."
          so uma correção: Utilizar uma tecnologia so porque esta na moda sem preocupara com requisitos de arquitetura é que na verdade não agrega muito. Utilizo Spring em alguns sistemas e poupa um pouco a programação chata de fazer factory  etc ...

          Em 8 de junho de 2011 08:58, wardog1 <wardog1@...> escreveu:
           

          DAO é um destes (poucos) mecanismos de programação que deu certo.

          Acredito, firmemente, que a simplificação é o único método confiável de se desenvolver código reutilizável.

          A abordagem mais simples que encontrei é a seguinte:

          1ª Parte

          1) DAO abstrato para cada tabela com as funções de insert, update, delete e de select sem joins com outras tabelas
          2) DAO concreto, para cada SGBD, com a implementação de 1)
          3) DAOFactory para instanciar 2) . É um DAOFactory por DAO abstrato.

          2ª Parte

          4) DAO abstrato para fazer consultas com joins. Este DAO deve ser organizado de acordo com regras de negócio. Ex.: DAO financeiro que precisa fazer consulta envolvendo joins com outras tabelas.
          5) DAO concreto, para cada SGBD, com a implementação de 4)
          6) DAOFactory para instanciar 5). É um DAOFactory por DAO abstrato.

          Obs. 1

          Outro aspecto importante é o uso de Facades para implementar regras de negócio. DAO deve ser utilizado somente para persistência/consulta deixando para o Facade utilizar os vários DAOFactory e consumir os serviços do DAO respectivo.

          Obs. 2

          Ao desenvolver sistemas de negócios, tenha em mente a seguinte abordagem:

          1) Nada é mais importante do que o modelo de banco de dados: é o único ativo de TI perene que sobrevive ao tempo. Dedique tempo, reflexão e persuasão para simplificá-lo ao máximo possível.

          2) Ao desenvolver seu MVC, DAO e Facade utilize ao mínimo a programação OO. A justificativa é simples: sistemas de negócios são procedurais. A linguagem OO é muito boa para desenvolver games e aplicações nais quais a programação procedural é inadequada, mas, para aplicações de negócios geralmente é um saco de tempo sem fundo.

          3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

          2011/6/7 Jean Jorge Michel <jeanjmichel@...>
           

          Boa noite pessoal.

          Queria saber dos amigos se vcs acham vantagem ter um DAO generico ao invés de DAOs para casa classe do sistema.
          Deixa eu ver se me faço entender.

          Hoje estou vendo um sistema onde TUDO é genérico. Ok, pode ser válido. Mas ai vem aquela pergunta: e o ovo, veio antes ou depois da galinha? Quando temos um DAO genérico e queremos algumas ações específicas para uma classe? Aqui foi feito um DAO para a classe X que estende o genérico e tal.... mas quase toda a classe tem sua peculiaridade, então são muitos DAOs estendendo o genérico.

          A Caelum no seu blog fala em interfaces para restringir o DAO genérico.
          Aí teremos um uma interface do DAO genérico > a implementação do DAO genérico > a Interface de restrição > o DAO que estende o genérico e implementa a interface. Ufa. Se eu vou ter isso para 30 classes eu posso economizar 30 interfaces não tendo esse DAO genérico.

          Queria o conselho, a experiência dos amigos sobre o assunto.

          Pela atenção obrigado.



          --
          Best regards,
          Jean J. Michel

          * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
          My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
          My Twitter: http://twitter.com/jeanjmichel



          --
          Att,

          Roberto Messa
          Analista/Programador Java Sênior
          21 72138181





          --
          ...........................................................................
          Gilmar Candido - Software Developer






        • Julio Cabral
          Não é flamewar. Eu só quero entender pq sistemas de negócio são  procedurais. E sobre a segunda questão, é fato, não tem discussão. Acredito que
          Message 4 of 22 , Jun 10, 2011
          View Source
          • 0 Attachment
            Não é flamewar.
            Eu só quero entender pq sistemas de negócio são  procedurais.

            E sobre a segunda questão, é fato, não tem discussão. Acredito que tenha sido uma brincadeira a colocação do nosso amigo.

            abs

            Julio

            --- Em sex, 10/6/11, Gilmar Candido <gilmarcand@...> escreveu:

            De: Gilmar Candido <gilmarcand@...>
            Assunto: Re: [riojug] DAO generico vale a pena?
            Para: riojug@yahoogroups.com
            Data: Sexta-feira, 10 de Junho de 2011, 15:48

             

            Não é flamewar, não é nem discussão. Mas de toda forma me desculpem, é claro que esta afirmação foi uma brincadeira.

            Em 10 de junho de 2011 15:38, Marcos Dantas <dantas.marcos@...> escreveu:
             

            Pessoal... defendam pontos de vista e não uma flamewar...
             


             
            Em 10 de junho de 2011 14:56, Gilmar Candido <gilmarcand@...> escreveu:
             

            "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir." 

            Como alguém tem coragem de escrever isto?



            Em 10 de junho de 2011 14:51, Julio Cabral <jcabral_br@...> escreveu:

             

            Prezados,

            Gostaria que me explicassem que conclusão é esta: "sistemas de negócios são procedurais."

            Em relação ao item
            3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

            99,99% dos desenvolvedores no mundo concordam que essas tecnologias agregam muito e não são tão complicadas para aprender. É só fazer certo e saber programar.

            grande abraço,

            Julio


            --- Em sex, 10/6/11, Valter Lobo - Imaginary Software System <valter.imaginary@...> escreveu:

            De: Valter Lobo - Imaginary Software System <valter.imaginary@...>
            Assunto: Re: [riojug] DAO generico vale a pena?
            Para: riojug@yahoogroups.com
            Data: Sexta-feira, 10 de Junho de 2011, 9:08

             

            Gostei desta afirmação :
            " Sistemas de negócios são procedurais."  e uma conclusão que tambem cheguei depois de 10 anos de experiência.

            isto tambem e muito valido :
            "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir."
            so uma correção: Utilizar uma tecnologia so porque esta na moda sem preocupara com requisitos de arquitetura é que na verdade não agrega muito. Utilizo Spring em alguns sistemas e poupa um pouco a programação chata de fazer factory  etc ...

            Em 8 de junho de 2011 08:58, wardog1 <wardog1@...> escreveu:
             

            DAO é um destes (poucos) mecanismos de programação que deu certo.

            Acredito, firmemente, que a simplificação é o único método confiável de se desenvolver código reutilizável.

            A abordagem mais simples que encontrei é a seguinte:

            1ª Parte

            1) DAO abstrato para cada tabela com as funções de insert, update, delete e de select sem joins com outras tabelas
            2) DAO concreto, para cada SGBD, com a implementação de 1)
            3) DAOFactory para instanciar 2) . É um DAOFactory por DAO abstrato.

            2ª Parte

            4) DAO abstrato para fazer consultas com joins. Este DAO deve ser organizado de acordo com regras de negócio. Ex.: DAO financeiro que precisa fazer consulta envolvendo joins com outras tabelas.
            5) DAO concreto, para cada SGBD, com a implementação de 4)
            6) DAOFactory para instanciar 5). É um DAOFactory por DAO abstrato.

            Obs. 1

            Outro aspecto importante é o uso de Facades para implementar regras de negócio. DAO deve ser utilizado somente para persistência/consulta deixando para o Facade utilizar os vários DAOFactory e consumir os serviços do DAO respectivo.

            Obs. 2

            Ao desenvolver sistemas de negócios, tenha em mente a seguinte abordagem:

            1) Nada é mais importante do que o modelo de banco de dados: é o único ativo de TI perene que sobrevive ao tempo. Dedique tempo, reflexão e persuasão para simplificá-lo ao máximo possível.

            2) Ao desenvolver seu MVC, DAO e Facade utilize ao mínimo a programação OO. A justificativa é simples: sistemas de negócios são procedurais. A linguagem OO é muito boa para desenvolver games e aplicações nais quais a programação procedural é inadequada, mas, para aplicações de negócios geralmente é um saco de tempo sem fundo.

            3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

            2011/6/7 Jean Jorge Michel <jeanjmichel@...>
             

            Boa noite pessoal.

            Queria saber dos amigos se vcs acham vantagem ter um DAO generico ao invés de DAOs para casa classe do sistema.
            Deixa eu ver se me faço entender.

            Hoje estou vendo um sistema onde TUDO é genérico. Ok, pode ser válido. Mas ai vem aquela pergunta: e o ovo, veio antes ou depois da galinha? Quando temos um DAO genérico e queremos algumas ações específicas para uma classe? Aqui foi feito um DAO para a classe X que estende o genérico e tal.... mas quase toda a classe tem sua peculiaridade, então são muitos DAOs estendendo o genérico.

            A Caelum no seu blog fala em interfaces para restringir o DAO genérico.
            Aí teremos um uma interface do DAO genérico > a implementação do DAO genérico > a Interface de restrição > o DAO que estende o genérico e implementa a interface. Ufa. Se eu vou ter isso para 30 classes eu posso economizar 30 interfaces não tendo esse DAO genérico.

            Queria o conselho, a experiência dos amigos sobre o assunto.

            Pela atenção obrigado.



            --
            Best regards,
            Jean J. Michel

            * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
            My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
            My Twitter: http://twitter.com/jeanjmichel



            --
            Att,

            Roberto Messa
            Analista/Programador Java Sênior
            21 72138181





            --
            ...........................................................................
            Gilmar Candido - Software Developer






          • Timothy High
            Oi, Essa é uma questão interessante. DAO é mais uma classe de design pattern obrigatório , e não gosto de nada que seja obrigatório ;) O Hibernate, e
            Message 5 of 22 , Jun 10, 2011
            View Source
            • 0 Attachment
              Oi,
              Essa é uma questão interessante. DAO é mais uma classe de "design pattern obrigatório", e não gosto de nada que seja obrigatório ;)
              O Hibernate, e por extensão, o JPA, foi criado com a concepção de "persistência transparente", ou seja, basta modificar os dados de uma entidade que ela será persistida sem mais nenhuma intervenção. Portanto, operações de alteração de entidades (e até de criação ou deleção de sub-entidades, tipo o endereço de um usuário) poderíam ser resolvidos sem nem recorrer a uma sessão, fábria ou DAO. Para outras operações, basta fazer chamadas à ubiquita sessão, de forma normalemente bastante simples. Isso tudo pode ser resolvido sem necessitar um DAO, sim.

              Então vale a pena a criação de DAO? Para quê que serve DAO? Como todos sabem, serve para separar todas as questões de persistência (menos às de transação e de saber da necessidade de persistência - e.g. saveOrUpdate()) em uma camada só. A vantagem principal é de facilitar a substituição do mecanismo de persistência atual por outro no futuro. Mas será que isso realmente é coisa de se preocupar? Vamos ver alguns casos:

              1. Trocar o banco MySQL por banco Oracle: em 95% dos casos, o Hibernate ou JPA conseguiria realizar essa modificação sem pouco ou tlvz nenhum impacto ao código que faz a persistência (o O/RM já fornece camada quase-completa de abstração do banco RDMBS específico)
              2. Trocar um método de query por entidades por outro de SQL puro, ou de stored procedure: sem DAO isso terá impacto no código de negócios. Na verdade, não seria muito diferente com DAO, só que o DAO tb funciona como centralizador da lógica de persistência. Então, se o mesmo método de query estiver espalhado e repetido em vários lugares no código (aliás, pq está fazendo copy-paste de código assim??), vai dar em problemas. 
              3. Trocar modelo OR/M (Hibernate/JPA) por outro (e.g. iBatis): só com DAO que será possível
              4. Trocar DB OO por Hibernate ou vice-versa: você é louco?? (mas já aconteceu comigo - e estava sem camada de DAO!) Sem DAO, vai dar trabalho
              5. Trocar DB por serviço remoto: DAO facilitaria, mas muitas vezes com uma mudança de paradigma tão radical, nem dá pro código procedural fingir que está usando banco ainda (e.g. mudança de síncrono pra assíncrono, novos tipos de erro, falta de transação, etc.)
              6. Trocar RDBMS por banco NoSQL: tb somente com DAO, mas DAO tlvz não seja suficiente
              7. Inserir uma camada de cacheamento: o próprio Hibernate oferece a possibilidade de gerenciar um cache "nível 2" de forma declarativa. Mas as vezes uma camada de cache precisa seguir lógico de negócio além do que é possível com apenas configuração. Tb nesses casos, o DAO nem sempre consegue atender sozinho.
              8. Trocar mecanismo de persistência por mock em teste unitário: confesso não conhecer todas as possibilidades com Hibernate/JPA neste caso, mas na prática, tivemos que usar um banco pequeno em memória (HSQLDB) para teste unitário com Hibernate, que nem sempre é confiável, e é muito mais lento. Se chamar o Hibernate direto dos objetos de negócios, vai complicar muito a execução de testes unitários.
              Nos casos 1 a 7, existe muita aplicação que nunca terá que lidar com esse tipo de mudança. Mas é difícil saber antemão. O caso 8 sozinha para mim é argumento suficiente para se criar uma camada separada de persistência (nota que isso não necessariamente significa DAO - quem trabalha com DDD pode chamar essa camada de repositório, por exemplo). O outro argumento a favor é o tal de "single responsibility principle". Ter que colocar HQL no meio do código transacional não me cheira bem.

              Um abraço,
              Tim.
               

              2011/6/10 Jean Jorge Michel <jeanjmichel@...>
               

              Ao contrário do que um camarada do CEJUG postou, risadinhas, eu gosto muito dessa troca de informações com vocês. O tópico gerou ramificações para OO, interfaces, etc. Além de questionamentos que eu ainda não tinha me feito :-) . Valeu a todos.

              No meu caso que não sou um arquiteto (e não terei nesse projeto um) e não conheço a fundo JPA/Hibernate (utilizei Hibernate em um sistema, mas tinham DAOs). Vou ter que me virar nos 30s mesmo.

              O que eu já "herdei" do sistema era algo como:

              JSF backing beans/managed beans: faz as validações e chama um ou vários facades
                Facade (toda a lógica. pode usar mais de um DAO)
                  DAO (usa Hibernate)
                    Banco

              Diria que me deixaram o feijão com arroz. E somente o desenho, sem uma classe implementada. Mas beleza.

              Depois que o desenvolvimento das classes de modelo e testes unitários terminou (testando algumas lógicas de modelo como relacionamento entre classes, repetições de dados em listas, etc) me perguntaram “e aí, DAO genérico ou não?”. Vim aqui trocar uma idéia com os mestres e me deparei com outra pi**, esses infernos de DAOs nem precisam existir!

              Pelo o que eu entendi o "melhor" seria eu fazer:

              Já que meus pobres POJOs estão repletos de anotações por "culpa" do Hibernate, eu ao invés de usar um DAO para DAOx.save(entidade) vou fazer isso no Facade. Certo?


              Valeu a todos que responderam com seriedade. Pra mim não ofende perguntar e gosto muito de poder usufruir da sabedoria da galera para aprender cada dia mais, já que aqui na empresa não tenho esse tipo de recurso :-)



              --

              Best regards,
              Jean J. Michel

              * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
              My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
              My Twitter: http://twitter.com/jeanjmichel


            • Timothy High
              Dizer que sistemas de negócio são procedurais é um pouco exagerado, mas não totalmente errado. Aprendemos todos os conceitos de programação OO, só pra
              Message 6 of 22 , Jun 10, 2011
              View Source
              • 0 Attachment
                Dizer que sistemas de negócio são procedurais é um pouco exagerado, mas não totalmente errado. Aprendemos todos os conceitos de programação OO, só pra cair de pára quedas no mundo "Java procedural" - servlet chama bean, bean chama façade, façade carrega tal dado, muda tal campo, manda um email, gera um relatório, e pronto! Tem muito sistema (ou, pelo menos, grande parte destes sistemas) que não tem lógica de negócios complexa, e portanto o código de "dominio" parece uma lista de tarefas. Isso, sim, é sistema procedural.

                Mas uma vez que as regras começam a se complicar (muda de "o que fazer" para "como fazer?"), é melhor começar a pensar em termos OO: qual a responsabilidade de cada classe, como se compor o relacionamento entre as participantes, como garantir o encapsulamento, etc.

                abs,
                Tim.

                2011/6/10 Julio Cabral <jcabral_br@...>
                 

                Não é flamewar.
                Eu só quero entender pq sistemas de negócio são  procedurais.

                E sobre a segunda questão, é fato, não tem discussão. Acredito que tenha sido uma brincadeira a colocação do nosso amigo.

                abs

                Julio

                --- Em sex, 10/6/11, Gilmar Candido <gilmarcand@...> escreveu:

                De: Gilmar Candido <gilmarcand@...>

                Assunto: Re: [riojug] DAO generico vale a pena?
                Para: riojug@yahoogroups.com
                Data: Sexta-feira, 10 de Junho de 2011, 15:48


                 

                Não é flamewar, não é nem discussão. Mas de toda forma me desculpem, é claro que esta afirmação foi uma brincadeira.

                Em 10 de junho de 2011 15:38, Marcos Dantas <dantas.marcos@...> escreveu:
                 

                Pessoal... defendam pontos de vista e não uma flamewar...
                 


                 
                Em 10 de junho de 2011 14:56, Gilmar Candido <gilmarcand@...> escreveu:
                 

                "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir." 

                Como alguém tem coragem de escrever isto?



                Em 10 de junho de 2011 14:51, Julio Cabral <jcabral_br@...> escreveu:

                 

                Prezados,

                Gostaria que me explicassem que conclusão é esta: "sistemas de negócios são procedurais."

                Em relação ao item
                3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

                99,99% dos desenvolvedores no mundo concordam que essas tecnologias agregam muito e não são tão complicadas para aprender. É só fazer certo e saber programar.

                grande abraço,

                Julio


                --- Em sex, 10/6/11, Valter Lobo - Imaginary Software System <valter.imaginary@...> escreveu:

                De: Valter Lobo - Imaginary Software System <valter.imaginary@...>
                Assunto: Re: [riojug] DAO generico vale a pena?
                Para: riojug@yahoogroups.com
                Data: Sexta-feira, 10 de Junho de 2011, 9:08

                 

                Gostei desta afirmação :
                " Sistemas de negócios são procedurais."  e uma conclusão que tambem cheguei depois de 10 anos de experiência.

                isto tambem e muito valido :
                "utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir."
                so uma correção: Utilizar uma tecnologia so porque esta na moda sem preocupara com requisitos de arquitetura é que na verdade não agrega muito. Utilizo Spring em alguns sistemas e poupa um pouco a programação chata de fazer factory  etc ...

                Em 8 de junho de 2011 08:58, wardog1 <wardog1@...> escreveu:
                 

                DAO é um destes (poucos) mecanismos de programação que deu certo.

                Acredito, firmemente, que a simplificação é o único método confiável de se desenvolver código reutilizável.

                A abordagem mais simples que encontrei é a seguinte:

                1ª Parte

                1) DAO abstrato para cada tabela com as funções de insert, update, delete e de select sem joins com outras tabelas
                2) DAO concreto, para cada SGBD, com a implementação de 1)
                3) DAOFactory para instanciar 2) . É um DAOFactory por DAO abstrato.

                2ª Parte

                4) DAO abstrato para fazer consultas com joins. Este DAO deve ser organizado de acordo com regras de negócio. Ex.: DAO financeiro que precisa fazer consulta envolvendo joins com outras tabelas.
                5) DAO concreto, para cada SGBD, com a implementação de 4)
                6) DAOFactory para instanciar 5). É um DAOFactory por DAO abstrato.

                Obs. 1

                Outro aspecto importante é o uso de Facades para implementar regras de negócio. DAO deve ser utilizado somente para persistência/consulta deixando para o Facade utilizar os vários DAOFactory e consumir os serviços do DAO respectivo.

                Obs. 2

                Ao desenvolver sistemas de negócios, tenha em mente a seguinte abordagem:

                1) Nada é mais importante do que o modelo de banco de dados: é o único ativo de TI perene que sobrevive ao tempo. Dedique tempo, reflexão e persuasão para simplificá-lo ao máximo possível.

                2) Ao desenvolver seu MVC, DAO e Facade utilize ao mínimo a programação OO. A justificativa é simples: sistemas de negócios são procedurais. A linguagem OO é muito boa para desenvolver games e aplicações nais quais a programação procedural é inadequada, mas, para aplicações de negócios geralmente é um saco de tempo sem fundo.

                3) Combata a ferro e fogo (ou se tu preferires, de forma serena, porém firme) , tentativas de utilizar modismos como Spring, Hibernate e Ajax. A justificativa é simples: agregam pouco e custam muito para aprender, implementar e manutenir.

                2011/6/7 Jean Jorge Michel <jeanjmichel@...>
                 

                Boa noite pessoal.

                Queria saber dos amigos se vcs acham vantagem ter um DAO generico ao invés de DAOs para casa classe do sistema.
                Deixa eu ver se me faço entender.

                Hoje estou vendo um sistema onde TUDO é genérico. Ok, pode ser válido. Mas ai vem aquela pergunta: e o ovo, veio antes ou depois da galinha? Quando temos um DAO genérico e queremos algumas ações específicas para uma classe? Aqui foi feito um DAO para a classe X que estende o genérico e tal.... mas quase toda a classe tem sua peculiaridade, então são muitos DAOs estendendo o genérico.

                A Caelum no seu blog fala em interfaces para restringir o DAO genérico.
                Aí teremos um uma interface do DAO genérico > a implementação do DAO genérico > a Interface de restrição > o DAO que estende o genérico e implementa a interface. Ufa. Se eu vou ter isso para 30 classes eu posso economizar 30 interfaces não tendo esse DAO genérico.

                Queria o conselho, a experiência dos amigos sobre o assunto.

                Pela atenção obrigado.



                --
                Best regards,
                Jean J. Michel

                * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
                My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
                My Twitter: http://twitter.com/jeanjmichel



                --
                Att,

                Roberto Messa
                Analista/Programador Java Sênior
                21 72138181





                --
                ...........................................................................
                Gilmar Candido - Software Developer







              • Jean Jorge Michel
                Tim, Tu mataste boas partes das dúvidas, e já de estamos quase certos de que terá um DAO aqui. O sistema fará muita pesquisa, alias é o propósito dele e
                Message 7 of 22 , Jun 13, 2011
                View Source
                • 0 Attachment

                  Tim,

                   

                  Tu mataste boas partes das dúvidas, e já de estamos quase certos de que terá um DAO aqui.

                   

                  O sistema fará muita pesquisa, alias é o propósito dele e os dados não mudarão muito.


                  Pra que seja entendido: hoje a empresa tem “fornecedores” de quase tudo que é serviço ou material de expediente. E como são muitos, estamos fazendo um sistema para o departamento de compras poder pesquisar nesses caras o que eles tem em estoque, o preço e o prazo de entrega, já dando um ranking da melhor escolha a pior. Os fornecedores por sua vez alimentam a sua base aqui dentro (webservices). Futuramente se estuda não ficar acessando o banco e sim usar uma estratégia de cachê ou NoSQL.

                  Como hoje a realidade é um SGBD mesmo, vamos de DAO e amanhã se/quando trocarmos isso, teremos menos dor de cabeça ;)

                   

                   

                  Valeu.

                  Em 10 de junho de 2011 19:04, Timothy High <timothy.high@...> escreveu:


                  Oi,
                  Essa é uma questão interessante. DAO é mais uma classe de "design pattern obrigatório", e não gosto de nada que seja obrigatório ;)
                  O Hibernate, e por extensão, o JPA, foi criado com a concepção de "persistência transparente", ou seja, basta modificar os dados de uma entidade que ela será persistida sem mais nenhuma intervenção. Portanto, operações de alteração de entidades (e até de criação ou deleção de sub-entidades, tipo o endereço de um usuário) poderíam ser resolvidos sem nem recorrer a uma sessão, fábria ou DAO. Para outras operações, basta fazer chamadas à ubiquita sessão, de forma normalemente bastante simples. Isso tudo pode ser resolvido sem necessitar um DAO, sim.

                  Então vale a pena a criação de DAO? Para quê que serve DAO? Como todos sabem, serve para separar todas as questões de persistência (menos às de transação e de saber da necessidade de persistência - e.g. saveOrUpdate()) em uma camada só. A vantagem principal é de facilitar a substituição do mecanismo de persistência atual por outro no futuro. Mas será que isso realmente é coisa de se preocupar? Vamos ver alguns casos:

                  1. Trocar o banco MySQL por banco Oracle: em 95% dos casos, o Hibernate ou JPA conseguiria realizar essa modificação sem pouco ou tlvz nenhum impacto ao código que faz a persistência (o O/RM já fornece camada quase-completa de abstração do banco RDMBS específico)
                  2. Trocar um método de query por entidades por outro de SQL puro, ou de stored procedure: sem DAO isso terá impacto no código de negócios. Na verdade, não seria muito diferente com DAO, só que o DAO tb funciona como centralizador da lógica de persistência. Então, se o mesmo método de query estiver espalhado e repetido em vários lugares no código (aliás, pq está fazendo copy-paste de código assim??), vai dar em problemas. 
                  3. Trocar modelo OR/M (Hibernate/JPA) por outro (e.g. iBatis): só com DAO que será possível
                  4. Trocar DB OO por Hibernate ou vice-versa: você é louco?? (mas já aconteceu comigo - e estava sem camada de DAO!) Sem DAO, vai dar trabalho
                  5. Trocar DB por serviço remoto: DAO facilitaria, mas muitas vezes com uma mudança de paradigma tão radical, nem dá pro código procedural fingir que está usando banco ainda (e.g. mudança de síncrono pra assíncrono, novos tipos de erro, falta de transação, etc.)
                  6. Trocar RDBMS por banco NoSQL: tb somente com DAO, mas DAO tlvz não seja suficiente
                  7. Inserir uma camada de cacheamento: o próprio Hibernate oferece a possibilidade de gerenciar um cache "nível 2" de forma declarativa. Mas as vezes uma camada de cache precisa seguir lógico de negócio além do que é possível com apenas configuração. Tb nesses casos, o DAO nem sempre consegue atender sozinho.
                  8. Trocar mecanismo de persistência por mock em teste unitário: confesso não conhecer todas as possibilidades com Hibernate/JPA neste caso, mas na prática, tivemos que usar um banco pequeno em memória (HSQLDB) para teste unitário com Hibernate, que nem sempre é confiável, e é muito mais lento. Se chamar o Hibernate direto dos objetos de negócios, vai complicar muito a execução de testes unitários.
                  Nos casos 1 a 7, existe muita aplicação que nunca terá que lidar com esse tipo de mudança. Mas é difícil saber antemão. O caso 8 sozinha para mim é argumento suficiente para se criar uma camada separada de persistência (nota que isso não necessariamente significa DAO - quem trabalha com DDD pode chamar essa camada de repositório, por exemplo). O outro argumento a favor é o tal de "single responsibility principle". Ter que colocar HQL no meio do código transacional não me cheira bem.

                  Um abraço,
                  Tim.
                   

                  2011/6/10 Jean Jorge Michel <jeanjmichel@...>
                   

                  Ao contrário do que um camarada do CEJUG postou, risadinhas, eu gosto muito dessa troca de informações com vocês. O tópico gerou ramificações para OO, interfaces, etc. Além de questionamentos que eu ainda não tinha me feito :-) . Valeu a todos.

                  No meu caso que não sou um arquiteto (e não terei nesse projeto um) e não conheço a fundo JPA/Hibernate (utilizei Hibernate em um sistema, mas tinham DAOs). Vou ter que me virar nos 30s mesmo.

                  O que eu já "herdei" do sistema era algo como:

                  JSF backing beans/managed beans: faz as validações e chama um ou vários facades
                    Facade (toda a lógica. pode usar mais de um DAO)
                      DAO (usa Hibernate)
                        Banco

                  Diria que me deixaram o feijão com arroz. E somente o desenho, sem uma classe implementada. Mas beleza.

                  Depois que o desenvolvimento das classes de modelo e testes unitários terminou (testando algumas lógicas de modelo como relacionamento entre classes, repetições de dados em listas, etc) me perguntaram “e aí, DAO genérico ou não?”. Vim aqui trocar uma idéia com os mestres e me deparei com outra pi**, esses infernos de DAOs nem precisam existir!

                  Pelo o que eu entendi o "melhor" seria eu fazer:

                  Já que meus pobres POJOs estão repletos de anotações por "culpa" do Hibernate, eu ao invés de usar um DAO para DAOx.save(entidade) vou fazer isso no Facade. Certo?


                  Valeu a todos que responderam com seriedade. Pra mim não ofende perguntar e gosto muito de poder usufruir da sabedoria da galera para aprender cada dia mais, já que aqui na empresa não tenho esse tipo de recurso :-)



                  --

                  Best regards,
                  Jean J. Michel

                  * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
                  My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
                  My Twitter: http://twitter.com/jeanjmichel







                  --
                  Best regards,
                  Jean J. Michel

                  * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
                  My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
                  My Twitter: http://twitter.com/jeanjmichel
                • Timothy High
                  Ótimo! E obrigado pelo feedback - é interessante conhecer mais o contexto do seu projeto! 2011/6/13 Jean Jorge Michel ... Ótimo! E
                  Message 8 of 22 , Jun 14, 2011
                  View Source
                  • 0 Attachment
                    Ótimo! E obrigado pelo feedback - é interessante conhecer mais o contexto do seu projeto!

                    2011/6/13 Jean Jorge Michel <jeanjmichel@...>
                     

                    Tim,

                     

                    Tu mataste boas partes das dúvidas, e já de estamos quase certos de que terá um DAO aqui.

                     

                    O sistema fará muita pesquisa, alias é o propósito dele e os dados não mudarão muito.


                    Pra que seja entendido: hoje a empresa tem “fornecedores” de quase tudo que é serviço ou material de expediente. E como são muitos, estamos fazendo um sistema para o departamento de compras poder pesquisar nesses caras o que eles tem em estoque, o preço e o prazo de entrega, já dando um ranking da melhor escolha a pior. Os fornecedores por sua vez alimentam a sua base aqui dentro (webservices). Futuramente se estuda não ficar acessando o banco e sim usar uma estratégia de cachê ou NoSQL.

                    Como hoje a realidade é um SGBD mesmo, vamos de DAO e amanhã se/quando trocarmos isso, teremos menos dor de cabeça ;)

                     

                     

                    Valeu.

                    Em 10 de junho de 2011 19:04, Timothy High <timothy.high@...> escreveu:



                    Oi,
                    Essa é uma questão interessante. DAO é mais uma classe de "design pattern obrigatório", e não gosto de nada que seja obrigatório ;)
                    O Hibernate, e por extensão, o JPA, foi criado com a concepção de "persistência transparente", ou seja, basta modificar os dados de uma entidade que ela será persistida sem mais nenhuma intervenção. Portanto, operações de alteração de entidades (e até de criação ou deleção de sub-entidades, tipo o endereço de um usuário) poderíam ser resolvidos sem nem recorrer a uma sessão, fábria ou DAO. Para outras operações, basta fazer chamadas à ubiquita sessão, de forma normalemente bastante simples. Isso tudo pode ser resolvido sem necessitar um DAO, sim.

                    Então vale a pena a criação de DAO? Para quê que serve DAO? Como todos sabem, serve para separar todas as questões de persistência (menos às de transação e de saber da necessidade de persistência - e.g. saveOrUpdate()) em uma camada só. A vantagem principal é de facilitar a substituição do mecanismo de persistência atual por outro no futuro. Mas será que isso realmente é coisa de se preocupar? Vamos ver alguns casos:

                    1. Trocar o banco MySQL por banco Oracle: em 95% dos casos, o Hibernate ou JPA conseguiria realizar essa modificação sem pouco ou tlvz nenhum impacto ao código que faz a persistência (o O/RM já fornece camada quase-completa de abstração do banco RDMBS específico)
                    2. Trocar um método de query por entidades por outro de SQL puro, ou de stored procedure: sem DAO isso terá impacto no código de negócios. Na verdade, não seria muito diferente com DAO, só que o DAO tb funciona como centralizador da lógica de persistência. Então, se o mesmo método de query estiver espalhado e repetido em vários lugares no código (aliás, pq está fazendo copy-paste de código assim??), vai dar em problemas. 
                    3. Trocar modelo OR/M (Hibernate/JPA) por outro (e.g. iBatis): só com DAO que será possível
                    4. Trocar DB OO por Hibernate ou vice-versa: você é louco?? (mas já aconteceu comigo - e estava sem camada de DAO!) Sem DAO, vai dar trabalho
                    5. Trocar DB por serviço remoto: DAO facilitaria, mas muitas vezes com uma mudança de paradigma tão radical, nem dá pro código procedural fingir que está usando banco ainda (e.g. mudança de síncrono pra assíncrono, novos tipos de erro, falta de transação, etc.)
                    6. Trocar RDBMS por banco NoSQL: tb somente com DAO, mas DAO tlvz não seja suficiente
                    7. Inserir uma camada de cacheamento: o próprio Hibernate oferece a possibilidade de gerenciar um cache "nível 2" de forma declarativa. Mas as vezes uma camada de cache precisa seguir lógico de negócio além do que é possível com apenas configuração. Tb nesses casos, o DAO nem sempre consegue atender sozinho.
                    8. Trocar mecanismo de persistência por mock em teste unitário: confesso não conhecer todas as possibilidades com Hibernate/JPA neste caso, mas na prática, tivemos que usar um banco pequeno em memória (HSQLDB) para teste unitário com Hibernate, que nem sempre é confiável, e é muito mais lento. Se chamar o Hibernate direto dos objetos de negócios, vai complicar muito a execução de testes unitários.
                    Nos casos 1 a 7, existe muita aplicação que nunca terá que lidar com esse tipo de mudança. Mas é difícil saber antemão. O caso 8 sozinha para mim é argumento suficiente para se criar uma camada separada de persistência (nota que isso não necessariamente significa DAO - quem trabalha com DDD pode chamar essa camada de repositório, por exemplo). O outro argumento a favor é o tal de "single responsibility principle". Ter que colocar HQL no meio do código transacional não me cheira bem.

                    Um abraço,
                    Tim.
                     

                    2011/6/10 Jean Jorge Michel <jeanjmichel@...>
                     

                    Ao contrário do que um camarada do CEJUG postou, risadinhas, eu gosto muito dessa troca de informações com vocês. O tópico gerou ramificações para OO, interfaces, etc. Além de questionamentos que eu ainda não tinha me feito :-) . Valeu a todos.

                    No meu caso que não sou um arquiteto (e não terei nesse projeto um) e não conheço a fundo JPA/Hibernate (utilizei Hibernate em um sistema, mas tinham DAOs). Vou ter que me virar nos 30s mesmo.

                    O que eu já "herdei" do sistema era algo como:

                    JSF backing beans/managed beans: faz as validações e chama um ou vários facades
                      Facade (toda a lógica. pode usar mais de um DAO)
                        DAO (usa Hibernate)
                          Banco

                    Diria que me deixaram o feijão com arroz. E somente o desenho, sem uma classe implementada. Mas beleza.

                    Depois que o desenvolvimento das classes de modelo e testes unitários terminou (testando algumas lógicas de modelo como relacionamento entre classes, repetições de dados em listas, etc) me perguntaram “e aí, DAO genérico ou não?”. Vim aqui trocar uma idéia com os mestres e me deparei com outra pi**, esses infernos de DAOs nem precisam existir!

                    Pelo o que eu entendi o "melhor" seria eu fazer:

                    Já que meus pobres POJOs estão repletos de anotações por "culpa" do Hibernate, eu ao invés de usar um DAO para DAOx.save(entidade) vou fazer isso no Facade. Certo?


                    Valeu a todos que responderam com seriedade. Pra mim não ofende perguntar e gosto muito de poder usufruir da sabedoria da galera para aprender cada dia mais, já que aqui na empresa não tenho esse tipo de recurso :-)



                    --

                    Best regards,
                    Jean J. Michel

                    * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
                    My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
                    My Twitter: http://twitter.com/jeanjmichel







                    --
                    Best regards,
                    Jean J. Michel

                    * Sent from my cellphone, please forgive the lack of accents and punctuation marks ;)
                    My blogs: http://www.jeanjmichel.blogspot.com and http://www.anonymousbiker.wordpress.com
                    My Twitter: http://twitter.com/jeanjmichel


                  Your message has been successfully submitted and would be delivered to recipients shortly.