Muitas pessoas reclamam que perdem o poder do SQL ao utilizar um mapeamento objeto-relacional como o Hibernate. Daniel Passos mostra que existem modos de “recuperar” este “poder”, caso necessário, claro.
Muitas pessoas reclamam que perdem o poder do SQL ao utilizar um mapeamento objeto-relacional como o Hibernate. Daniel Passos mostra que existem modos de “recuperar” este “poder”, caso necessário, claro.
Programador fica se preocupando com um campinho na projeção ao invés de se preocupar com coisas que afetam muito mais a performance do sistema como um todo. Convencer os DBAs a fazer um schema decente, por exemplo.
Não é tão simples assim Diego…
As vezes requisitos de performace são definidos por contrato. Usando o Hibernate 2 várias vezes tive que usar JDBC na mão por problemas de performace.
O Hibernate 3 facilita muito isso.
Caminho errado.
SQL ainda é muito mais simples que Java. E poderoso. E de melhor desempenho.
Impressionante como o povo procedural (orientação a objeto) tem dificuldade de aprender a pensar declarativamente (relacional).
Leonardo,
SQL não pode ser de melhor desempenho que Java porque eles lidam com coisas diferentes. Em Java, seja com Hibernate ou não, você vai criar uma consulta SQL, então sua afirmação não faz sentido.
Da mesma forma, o problema não é declarativo x imperativo (o antagonista de declarativo é imperativo, não necessariamente procedural) já que mesmo HQL, XPath e outras linguagens que são utilizadas como alternativas ao uso -direto- de SQL são declarativas.
O ponto do artigo do Daniel e de APIs e bibliotecas como Hibernate Criteria é que muitas vezes não é fácil gerar código em SQL (ou HQL ou qualquer outra linguagem) concatenando Strings, utilizando uma API OO você consegue fazer isso de maneira extremamente simples e natural.
Quanto ao uso do Hibernate em si, se você me explicar como eu faço ORM, consultas polimórficas e Lazy Loading (algumas características simples do Hibernate) utilizando apenas SQL eu agradeço.