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

Re: [riojug] Re: [DFJUG] Desafio (DAO + DAOFactory) X (Spring + Hibernate + Generics)

Expand Messages
  • Alex Rios
    Pessoal, To pensando aqui, se o motivo de criar 1 DAO é obter as conexões, mapear objetos para tipos de dados da sua base e executar comandos SQL, certo?
    Message 1 of 44 , Jan 8, 2010
    • 0 Attachment
      Pessoal,
      To pensando aqui, se o motivo de criar 1 DAO é obter as conexões, mapear objetos para tipos de dados da sua base e executar comandos SQL, certo?

      Entao se o Hibernate já faz esse serviço/trabalho qual o motivo então para se criar uma DAO quando se usa Hibernate?

      Adoro tópicos desses se aprende muito =]

      2010/1/8 wardog1 <wardog1@...>
       

      Fabio,

      O desafio tem a intenção de um exemplo bem simples e rápido de entender.

      Tu poderias modificar a tua versão para se restringir ao desafio?

      Digo, para mim não precisar mexer no teu código. Depois de analizar este exemplo, podemos complicar um pouco mais e colocar as outras classes.

      Uma coisa de cada vez.

      --
      Att,
      http://pageletbox.com
      Framework PHP para Celular
      21 95842096

      Tutorial CRUD para Celular WAP: Parte 1 - Especificação e Protótipo consulta



      2010/1/7 fabiolnm <fabio.ita04@...>

      Esqueci de mencionar um último ponto: quando vc mencionou concorrência, disse que era necessário compartilhar a mesma conexão... Não entendi bem, mas é bom lembrar/informar que existem aplicações onde:
      • é necessário salvar dados em vários bancos de dados, e em uma única transação. Vc lida, portanto, com várias conexões!!! Se uma operação falhar, todas devem ser desfeitas.
      • é necessário usar transações em operações que envolvem recursos heterogêneos (por exemplo, BDs e filas JMS). O mesmo princípio continua válido: se algo falhar, desfazer tudo.
      • é necessário "orquestrar" operações usando serviços/sistemas heterogêneos, onde muita coisa escapa totalmente de seu controle (são desenvolvidas por outras equipes ou mesmo empresas...)
      Confesso nunca ter vivenciado experiências diretas com isso, mas são conceitos e cenários interessantes, que estudei em um livro de Padrões de Projeto para transações. 

      Note, que vc pode se considerar um cara de sorte, por nunca ter se deparado com problemas assim, mas vai que uma oportunidade dos sonhos aparece, para vc ganhar bastante $$$... Vai acabar tendo que comer nos pratos que hj vc rejeita...

      enfim, jah deixei muito mais que 2C, e desta vez me retiro da discussão. Mas prontamente retorno, caso o objetivo seja transformar o desafio em um grande tutorial comparando as várias soluções que podem ser dadas para aquele problema.

      abs!



      2010/1/7 Fabio Miranda <fabio.ita04@...>
      Roberto,

      Pré-PS: dediquei os últimos 40 minutos escrevendo esta última tentativa de apaziguar os ânimos, e mostrar outros horizontes. Não espero que concordes, ou compreendas, mas vai ajudar muito se não me chamar de mané, como vens fazendo com todo mundo! Vamos manter a lista limpa, sem flame wars, ok? :-P 

      ##########################################################################################################

      Tenha calma. Desacelera. Pega leve. Todos que estão nesta lista estão dispostos a ajudar. São voluntários. Investem parte de seu tempo para fortalecer os colegas, e também como gratidão à riqueza de informações que a comunidade oferece. Quando vc defende suas idéias desferindo ataques aos colegas, está menosprezando também os anos e anos de experiência de todos. Se esta lista tem 1000 usuários, mesmo que cada usuário tenha apenas 1 ano de experiência, são 1000 anos contra 11. Vc está fechando portas e deixando de fazer amizades. Bom networking é essencial em toda profissão!

      Todos os desenvolvedores compartilham histórias em comum, e normalmente os primeiros 5 a 10 anos de carreira costumam ser mesmo turbulentos. Muitos de nós já se meteu em encrencas e passou noites e noites em claro! A experiência que vc compartilha, de criar um framework doméstico, eu tb vivenciei no início da carreira. 

      Após passar por Struts, Spring MVC, JBoss Seam, também me sentia limitado, e não conseguia desenvolver os projetos com a qualidade que eu queria, e dentro dos prazos que deveria. Não porque elas eram ruins, mas porque eu não conseguia tirar o máximo delas. Mas também aprendi muita coisa, e para resolver os problemas imediatos, também criei uma framework doméstica.

      Ela me atendeu muito bem durante os últimos dois anos, mas perante os novos desafios, vejo o quanto ela é limitada (tenho uma aplicação que não pára de crescer, necessidade de colocá-la nas nuvens, necessidade de prover uma interface mais rica e amigável, necessidade de treinar mais funcionários para usar essa biblioteca; e como se não bastasse, ainda preciso quebrar a aplicação em módulos menores, para que seja comercialmente mais acessível a pequenos clientes....). 

      Respire, reflita, não tenha vergonha de ser eterno aprendiz. As tecnologias estão evoluindo em velocidade estonteante, mesmo a pessoa mais experiente com certeza deve estar se sentindo perdido! No mais, pelos depoimentos abaixo, fica muito evidente que os projetos que vc tem desenvolvido são relativamente simples. Não estou menosprezando seu trabalho, mas por exemplo:
      1. No desafio que respondi mais cedo, consegui fazer um modelamento ER transparente, usando tecnologia Objeto-Relacional. Verifique nas tabelas: elas estão todas normalizadas. Poderia estender o exemplo, mostrando o quanto HQLs de consulta são mais simples de escrever do que os SQLs correspondentes. E sem perder as capacidades de JOINs, por exemplo.
      2. Com o Cloud Computing, uma nova abordagem de tratamento de dados está emergindo. A normalização não é mais um mandamento. Estamos aqui falando de sistemas com MUITOS DADOS, MUITOS USUÁRIOS, MUITOS ACESSOS SIMULTÂNEOS. Como deixar sua aplicação escalável para estes cenários? Sugiro que vc dê uma olhada em algumas palestras do Google Developer Days 2009 (estão legendadas) para ter uma idéia da complexidade para desenvolver sistemas assim. Por exemplo: http://www.youtube.com/watch?v=BFBgeQlJCWM.
      3. Cache: é uma das Key Features do App Engine. A Google usa isso em seus aplicativos e não se pode questionar o sucesso das aplicações que eles desenvolvem (ou será que vc pode?)... Nunca usei, mas também não parece ser assim um monstro de sete cabeças...
      4. Concorrência: é um puta desafio computacional, já rendeu e continua rendendo muitas teses de mestrado/doutorado, etc... Por mais que desejemos utilizá-la de forma transparente, em algum momento, algum gargalo acaba aparecendo, e é necessário "sujar as mãos..."
      5. Tolerância a falhas: veja o vídeo que indiquei acima e vc terá uma noçao melhor do que se trata. Em sistemas pequenos isso não costuma ser um problema, mas em sistemas de missão crítica, deve ser levado bastante a sério.
      6. Consumo de memória: se tua aplicação tem muitos usuários, ou muito processamento, vc vai fazer escalabilidade vertical? Horizontal? Sujar as mãos com isso? Ou embarcar nas tecnologias Platform As A Service, e se preocupar apenas com as necessidades de negócio de sua aplicação?
      7. É muita viagem imaginar que tanta gente esteja trabalhando em coisas inúteis...
      8. Fazer projetos dentro do prazo e custo é nossa obrigação. Impressionar nossos clientes, com sistemas de qualidade, escaláveis, tolerantes a falhas, testáveis, integráveis, etc etc etc, é nosso desafio. E ganhar $$$ com isso, gerar empregos, etc etc etc é nosso objetivo, sonho, ou o que quer q vc chame.
      9. Certificados têm pelo menos 1 serventia: assegurar para nós mesmos que conhecemos bem a linguagem e que estamos utilizando adequadamente os recursos que ela oferece. Tenho 6 anos de experiência, e assim como vc, nunca tive tempo para tirar uma certificação, mas é algo que almejo fazer, tão logo tenha oportunidade.
      10. No mais, em outro email vc diz que usa MVC, DaoFactories, Session Facades. Vc está se referindo à framework, ou todos estes patterns estão presentes no desafio que vc propôs? Note outra coisa: vc está aplicando 4 patterns, isso é bom. Mas existem tantos outros! E os autores são os mesmos que também levantam a bandeira desses 4 que vc usa. Será que eles só acertaram os 4 patterns e todo o resto é lixo?
      Abs pacificadores!
      Fábio Miranda.

      2010/1/7 Roberto Messa <wardog1@...>


      2010/1/7 flaviocysne <flaviocysne@...>

      Roberto,

          você consegue imaginar fazer esse código braçal para mais de cem tabelas em um banco de dados de uma corporação (onde com certeza cem tabelas é ainda muito pouco) ?

      Com certeza!

      Um sistema começa com um bom modelamento de banco de dados e não com o besteirol de modelagem orientada a objeto.

      A partir de uma primeira modelagem, DAOs vão sendo confeccionados e reaproveitados em Session Facades de forma lenta, gradual e segura.
       
      Tente não ser simplista demais em suas abordagens. O JPA não é só para diminuir o trabalho dos "preguiçosos" (eu, com certeza, posso me incluir nessa contagem) e sim para abstrair do desenvolvedor um série de outros fatores que um só não dá conta, como:
       
      Cache: deve ser adquirido um produto para isto:
      desenvolvedores não devem nem passar perto disto

      Concorrência:
      tarefa para o banco de dados: o desenvolvedor deve apenas se preocupar em utiliza a mesma conexão em todos os DAOs

      Tolerância a falhas:
      tarefa para o banco de dados e hardware: o desenvolvedor deve apenas se preocupar em utiliza a mesma conexão em todos os DAOs

      consumo de memória:
      geralmente só é problema para quem usa produtos convergentes como hibernate. quem não usa consegue um código simples e transacional que libera rapidamente a memória

      É muita viagem que uma biblioteca ajude a resolver estes problemas.

      Esse seu desafio não tem nada a acrescentar. Tente fazer um desafio montando um diagrama para uma esquema com pelo menos 50 entidades, peça também um teste de carga, teste de stress, gráficos de consumo de memória. Daí então você vai perceber que essas suas linhas a mais não valem de nada.

      Flávio, primeiro tu dá um jeito de montar e manutenir um sistema dentro do prazo e custo.

      Depois tu podes fazer estes testes e, se estiver dando problema de desempenho, podes ter certeza que o problema está nas queries ou no hardware.

      Em nenhum dos casos soluções convergentes como o Hibernate ou desprovidas de sentido como o Spring ajudam.

      Pra falar a verdade, só aumentam curva de aprendizado, custo e prazo
       

          Claro que opiniões pode ser divergentes. Cada um tem a sua. Ridicularizar uma pessoa ou menosprezar uma biblioteca construída por um time de desenvolvedores (que devem ter bem mais certificados que você) é no mínimo arrogância demais.

      Grande coisa ser certificado.

      Tenho 11 anos de java não tenho nenhuma certificação e não vou tirar nenhuma a não ser que algum incompetente me obrigue a fazer isto (ele pagando é claro).

      Não menosprezo estas bibliotecas. Digo que elas mais atrapalham do que ajudam e isto não é ridicularizar ninguém.

       

      Atenciosamente,

      Flávio Cysne.

      2010/1/7 Roberto Messa <wardog1@...>

      Já que tem muitos participantes sensíveis a opiniões mais diretas, vou tentar pegar mais leve, pois não quero fazer ninguém chorar :((

      Para os defensores do (hibernate + generics + spring + não sei o quê) que acham que utilizando estas coisas o trabalho fica mais fácil e produtivo, proponho o seguinte desafio:

      1) Transformar o código abaixo para utilizar (generics + hibernate + struts)
      2) Calcular a quantidade de linhas a mais ou a menos
      3) Debatermos os resultados

      Acredito que estes fóruns possam ser mais úteis que ficar ajudando em dúvidas mixurucas que devia ser resolvidas com consultas a mecanismos de busca.

      class ProdutoDAO {
          abstract void insereProduto(nome, preço);

          void verificaPreço(preço) {
              if(preço < 0)
              throw new PrecoInvalidoException();
          }
      }

      class ProdutoDAOImpl extends ProdutoDAO {
          void insereProduto(nome, preço) {
              DbConn    dbConn    = DbConnFactory.getDbConn();
              dbConn.prepareSQL("insert into produto (nome, preco) values (?, ?)");
              dbConn.setParam(1, nome);
              dbConn.setParam(1, preço);
              dbConn.exec();
      }

      class ProdutoDAOFactory {
          static MYSQL    = 0;

          static ProdutoDAO getInstance(int dbType) {
              switch(dbType) {
                  case MYSQL:
                      return new ProdutoDAOImpl();
              }
          }
      }

      public static void main(String[] params) {
          int dbType    = ProdutoDAOFactory.MYSQL;

          ProdutoDAO produtoDAO     = ProdutoDAOFactory.getInstance(
      dbType);
          produtoDAO.insereProduto("Feijão", 1.25);
      }


      2009/12/22 Andre Fonseca <aoqfonseca@...>
       

      Pessoal,


      obrigado pela discussão, acredito que todos expuseram suas opinião e foi muito relevante ver os argumentos pois nos ajuda muito a formar uma visão pois a maioria de nós um dia pode vir acabando a ter que tomar uma decisão de arquitetura.

      Tenho minhas conclusões mas para evitar extender mais ainda esse tópico vou guardá-las, embora concorde com um pouco de cada. 

      Fazendo meu papel chato, peço que encerrem este tópico pois a coisa foi além do necessário e bom. Descambou para um lado ruim da "flame war". 

      Peço que não insistam em responder e convido aos protagonistas da discussão (Wardog principalmente) a elaborem um artigo e coloque em nosso blog ou em seus próprios blogs indicando posteriormente a url para apontarmos. 

      Esse tipo de conversa, desde que mantido o nível saudável e respeitoso sempre enriquecem a todos. 

      Insisto em pedir para acabar com a discussão. Vamos usar as outras ferramentas que são mais apropriadas para isso 9wiki e blog) . 
      Caso alguém insista será colocado em moderação pelo bem da coletividade. :D 


      --
      Att,

      Roberto Messa
      http://sybrain.com
      ERP para Celular
      21 95842096


      DFJUG 11 Anos.
      

      cancelar assinatura - página do grupo

      DFJUG 11 Anos.
      

      cancelar assinatura - página do grupo



      --
      Att,

      Roberto Messa
      http://sybrain.com
      ERP para Celular
      21 95842096
      DFJUG 11 Anos.
      

      cancelar assinatura - página do grupo





      --
      Atenciosamente,
      Alex Rios

      f5refresh.wordpress.com
    • Victor Hogemann
      Respondendo, ... Eu desenvolvo em HSQLDB e faço deploy em produção em Oracle. Os testes unitários são feitos contra HSQLDB. Já lidei com migrações de
      Message 44 of 44 , Jan 26, 2010
      • 0 Attachment
        Respondendo,

        Esse argumento não tem cabimento:

        1) Não é todo dia que uma empresa muda de BD. Consequentemente, não agrega valor e, mesmo se trocar, é altamente provável que TODO o sistema vá ser reavaliado e muito modificado. As pessoas aproveitam que tem que mexer mesmo para mudar outras coisas inclusive o código
        2) Como ficam functions e procedures nativas do banco e utilizadas nas queries? O Hibernate implementa todas infinitamente?

        Eu desenvolvo em HSQLDB e faço deploy em produção em Oracle. Os testes unitários são feitos contra HSQLDB. Já lidei com migrações de SQLServer pra Oracle, onde essa habilidade do Hibernate foi bem útil.

        Sobre functions e procedures... o Banco é de DADOS. Procedure e Trigger são bacalhaus horrorosos.
        • Lidar automaticamente com relacionamentos complexos entre entidades.
        É muita fantasia achar que um conceito convergente como o ORM vai lidar com isso melhor do que uma linguagem especializada como o SQL

        "É muita fantasia achar que um conceito convergente como linguagens de alto nível e compiladores lidem melhor com isso que uma linguagem especializada como Assembly."

        • Linguagem de consulta poderosa, que consegue expressar conceitos OO como herança e especialização
        Se isso funcionasse (e NÃO funciona), o BANCO  de dados orientado a OBJETO seria um sucesso. Mas não é. É um fracasso completo.
        A realidade mostra que o BANCO de dados RELACIONAL continua REI.

        Você está misturando alhos com bugalhos. O papel do hibernate é diminuir a impedancia que existe entre o modelo relacional e o modelo OO. A idéia é que você possa utilizar o melhor dos dois mundos.
        Principais desvantagens:
        • Curva de aprendizado. Pode confundir quem está começando e não conhece o suficiente de Java, OO e modelo relacional.
        Mesmo quem conhece muito java tem dificuldade em aprender Hibernate e Spring, pois são conceitos convergentes e, consequentemente, difíceis de entender, pois são antinaturais.

        Conceitos convergentes? Antinaturais? Dá pra elaborar melhor isso, sinceramente eu não entendi o que você quis dizer.

        Outra, eu não me considero um gênio, mas Hibernate e Spring são simples de entender pra mim. Então não acho um argumento válido extrapolar as suas dificuldades pro restante das pessoas.
         
        • Algumas queries geradas para relacionamentos complexos podem ser ineficientes. Obriga você a contornar utilizando SQL.
        Sempre achei que o refletion do java era uma boa idéia, mas acabou permitindo a existência de monstrengos como o Spring e o Hibernate.

        É CLARO que vai ter queda de desempenho com o SQL gerado pelo Hibernate.

        Não, não é claro. 99% do tempo o SQL gerado é o mesmo que você teria escrito na mão, só em alguns corner-cases que é necessário intervir manualmente.

        A raridade com que isto acontece (trocar a implementação de um DAO) já é o suficiente para desautorizar o uso dessa coisa.
        E, se precisa trocar a implementação, é pq a regra de negócio mudou e, consequentemente, é necessário a mudança do código (fala sério).
        O Spring promove e encoraja o desacoplamento entre os diversos componentes da sua aplicação, e isso é uma COISA BOA (TM).
        Desacoplamento se faz com Design Patterns e não com besteirol de XML.

        Em projetos complexos não é incomum existirem vários repositórios diferentes pros mesmos tipos de dados. Um exemplo do meu dia-a-dia seria Banco de Dados e índice Lucene. Mas também precisamos lidar com geração de XML e um ou outro arquivo texto.

        Na documentação do Spring ele a todo instante prega que você deve programar para interfaces, ou seja, definir bem os protocolos de comunicação entre os diversos serviços da sua aplicação. De forma que as implementações fiquem transparentes para quem as consome, promovendo o desacoplamento.

        Principais vantagens, na minha opinião:
        • Concentra em um único lugar a gerência dos componentes da sua aplicação.
        Não, não é abstrato. Em um projeto complexo, ter um local certo onde você pode levantar todos os relacionamentos e dependências entre os serviços da sua aplicação é uma mão na roda. 
        • Oferece uma alternativa mais simples ao pattern Factory.
        Só pq é "um arquivinho" a ser editado? No way

        Não, porquê praticamente elimina a necessidade de Factories. E porquê fica muito mais claro quem está consumindo o quê... basta olhar o xml de contexto. 
        • Garante pra você que um determinado objeto seja Singleton, sem necessidade de implementar esse pattern na classe em questão.
        Grande coisa ter que implementar um Singleton, que, diga-se de passagem, é outro que raramente é usado e, mais uma vez, desautorizando o uso de framework para isto

        Singleton raramente usado? LOL. 
        • Integração com as principais tecnologias Java: JDBC, JMS, JNDI, JPA, Hibernate, JTA, etc...
        É verdade e, até tu aprenderes a fazer tudo funcionar, vai um boooooooooooooooooom tempo

        Novamente, não é um argumento válido você extrapolar as suas dificuldades pra todo mundo. Fazer essas coisas funcionarem é uma necessidade do meu dia-a-dia. Assim como é uma necessidade explicar pros novatos aqui da empresa como essas coisas funcionam, o que não leva tanto tempo assim.
        • Curva de aprendizado bem suave (pro container de IOC)
        Aprender esse coisa não suave nem aqui e nem no inferno!

        Estou começando a desconfiar que o seu problema é que você não gosta de Hibernate e Spring por não ter conseguido entender como funcionam.

        [ ]s

        --
        Att,

        Roberto Messa
        http://sybrain.com
        ERP para Celular
        21 95842096




        --
        Victor Guilherme Hogemann
        http://victor.hogemann.eti.br
      Your message has been successfully submitted and would be delivered to recipients shortly.