fredferrao wrote:Saber SQL é legal e essencial, mas ficar fazendo CRUD o dia todo escrevendo um monte disso o dia inteiro enche o saco.

E aos que gostam de escrever o sql na unha, não se esqueçam de usar SQL/ANSI PURINHO, porque se começarem a usar features especificas do BD, rezem para um dia nao precisarem mudar de SGBD Imaginem o tamanho do refactory de um sistema grandinho, sair pescando as querys e mudando as coisas especificas de BD.

O que eu acho interessante é que as críticas se referem ao esforço que é necessário empregar para aprender a usar o Hibernate, como se não fosse necessário empregar qualquer esforço para aprender JDBC ou qualquer dos correlatos substitutos.

saoj wrote:


Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.

saoj wrote:
Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.

Rubem Azenha wrote:

Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box.

Rubem Azenha wrote:Não vejo problema nenhum em não gostar de ferramentas/conceitos bem estabelecidos. Mas quando falamos de tecnologia e desenvolvimento, temos que que ter um olhar mais técnico e menos emocional. Se não gostamos de uma ferramenta que todo mundo gosta, nós podemos estar certos, mas seria bom entendermos o que realmente não gostamos na ferramenta e ter a mente aberta, pode ser que nós simplesmente não conhecemos a ferramenta o suficiente ou nunca trabalhamos num ambiente em que ela é usada de forma correta.

asaudate wrote:

Felagund wrote:

asaudate wrote:Parando de trollar um pouco (ou não):

Acho que só não gosta de um framework quem não sabe usar e/ou não sabe pra que serve. Ex.: quem foi aí que comentou que o Hibernate é pouco flexível pq não suporta NoSQL, mesmo??

[]´s

Eu disse

Então, cara... o caso é que o Hibernate, como ferramenta ORM é feito para trabalhar somente com bancos de dados relacionais. Na verdade, existem tentativas de usar o Hibernate com bancos como o BigTable, do Google App Engine, mas o pessoal que já fez isso admite que fica muito ruim de trabalhar e admite, também, que é melhor usar outras estratégias.

Então, recapitulando... JPA (Hibernate) != Bancos NoSQL, OK ?

[]´s!!!

Rubem Azenha wrote:

saoj wrote:
Sim. Se vc não sabe nada, então é melhor partir para o Hibernate mesmo. O mercado aceita, etc. O problema é quem já sabia SQL, banco-de-dados, cache, blah, blah, e agora tem que esquecer isso e aprender um novo paradigma. O cara tem que se convencer que os benefícios superam os custos. Posso estar errado, mas não estou convencido disso. Pelo menos em todas as vezes que usei Hibernate.

Errado, na minha opinião. O hibernate não tem nenhum paradigma novo. Ele é um framework de persistencia/ORM. Se você programa decentemente a tua persistencia, você vai implementar na mão várias coisas que o Hibernate já tem implementado out-of-the-box.
Quem conhece bem Hibernate e depois le o PoEAA percebe que ele implementa vários patterns complexos, alguns inclusive que você dificilmente se daria o trabalho de implementar na mão (principalmente o Unit of Work). Cache da forma como ele faz nem se fala. Lazy loading, carregar automaticamente relacionamentos, etc, são outras coisas bem legais dele. Sem falar nos projetos Hibernate Search, Hibernate Validator, etc.

Tudo isso tem um custo, ele tem uma forma de se trabalhar e você precisa configurar ele. Mas hoje em dia a configuração dele é ridiculamente simples. O Hibernate em si é um projeto grande, tem uma complexidade, devido ao conjunto de conceitos e funcionalidades que ele implementa. Por isso é preciso ler a documentação e consultar a documentação constantemente.

Eu vejo muito desenvolvedor que não tem muita paciência e vai reinventando a roda, codificando tudo do zero. Eu acho que quem faz isso não é por que já sabe SQL e JDBC, e sim por que não tem conhecimento das ferramentas disponíveis. Por preguiça, má vontade, gosto pessoal e outros motivos, prefere não gastar tempo aprendendo bem uma ferramenta bem estabelecida que já faz muito bem o que ele precisa.

E não da pra comparar Hibernate com VB e Maker. Abstrair e implementar conceitos encapsulando suas complexidades é uma coisa, ferramenta visual para gerar código é outra.

Não vejo problema nenhum em não gostar de ferramentas/conceitos bem estabelecidos. Mas quando falamos de tecnologia e desenvolvimento, temos que que ter um olhar mais técnico e menos emocional. Se não gostamos de uma ferramenta que todo mundo gosta, nós podemos estar certos, mas seria bom entendermos o que realmente não gostamos na ferramenta e ter a mente aberta, pode ser que nós simplesmente não conhecemos a ferramenta o suficiente ou nunca trabalhamos num ambiente em que ela é usada de forma correta.

Anime wrote:Que polemica...

Já que é para abandonar o velhor e usar o novo,só por que a maioria está usando ,então quem usa eclipse está ultrapassado,abandonem isso e comecem a utilizar Netbeans.

Desculpe,mas tem gente viajando...

Ataxexe wrote:

Anime wrote:Que polemica...

Já que é para abandonar o velhor e usar o novo,só por que a maioria está usando ,então quem usa eclipse está ultrapassado,abandonem isso e comecem a utilizar Netbeans.

Desculpe,mas tem gente viajando...

Por esse ponto, os dois IDEs são velhos. O próprio Hibernate é bem velho também, assim como todo o resto exposto no tópico.

E é claro que não funciona assim. O ponto do Rubem é exatamente que não devemos levar no emocional decisões tecnológicas justamente porque a tecnologia não é emocional.

Isto sim é uma decisão racional:

http://community.jboss.org/wiki/Gradlewhy

Pra quem não irá ver o link, ele conta os motivos que levaram o time do Hibernate a deixar de usar o Maven e passar a usar o Gradle. São motivos parecidos que estão me levando a usar o Gradle na empresa, mas em casa o Maven me atende. É uma questão racional e não emocional.