Você não gosta do Hibernate? Eu tb não! Leia para entender o porquê

Assuntos Gerais
#41

Boa noite a todos,

Por mais divergentes que foram as opiniões o mais importante foi atingido que foi o fato de pararmos pra refletir sobre as tecnologias existentes. Parabéns aos que participaram e principalmente ao nosso amigo “saoj” que iniciou a discussão e nos fez refletir sobre tudo isso. Salvo as discusões mais acirradas onde cada um defendeu seu ponto de vista e que ninguém é obrigado a pensar de forma igual o resultado foi muito bom. O melhor framework não deve ser A ou B e sim consideramos que o melhor é o que dominamos, que sabemos usar e que nos propicia o melhor resultado para o projeto que estamos utilizando. Com certeza o Hibernate é um ótimo framework e senão o melhor, porém cabe a ressalva de que nem tudo é perfeito nessa vida. Não existe ainda esse mundo que queremos. E por mais que se faça num framework não será possível agradar a todos. Ainda bem que isso ocorre pois assim abre novas oportunidades para outros produtos. Talvez uma das falhas da discussão foi a forma como foi abordado o tema “Você não gosta do Hibernate?”, talvez desse ser “O que eu gostaria que o Hibernate fizesse e não faz” ou “O que vc acha deveria ser diferente no Hibernate?”. De tudo o que li algo me fez refletir sobre o que realmente é interessante e tevo um assunto que me chamou a atenção e que com certeza
estarei me aprofundando nos próximos dias “Configuração programática”. Com certeza vou poder tirar algo proveitoso dessa nova forma de pensamento que até então eu desconsiderei.

Espero que possamos nos encontrar em novos posts para discutirmos mais sobre outros assuntos.

Bom final de semana a todos,

Edson Martins

#42

Cara, isso é um absurdo! Aonde eu disse que o hibernate é maravilhoso? Tu colocou como um comentário meu algo que eu não disse em lugar nenhum! É só ler os meus posts. O que eu disse é que gosto do hibernate, da mesma forma que você disse que não gosta. Eu não posso em cima do que você disse colocar um comentário seu assim, saoj: “Eu odeio o hibernate!”

Isso só demonstra que você se utiliza de falácias para desacreditar não só as ferramentas, mas as pessoas e promover seus argumentos. Eu usei argumentos técnicos suficientes e sempre disse que uma ferramenta não é melhor que outra. Eu disse que gosto é uma coisa que não se discute. Ai você inventa um comentário que eu não fiz e diz que meus comentários são passionais de modo a me desacreditar! Afinal quem está sendo passional?

Lamentável!

#43

Foi uma ironia, por isso coloquei entre aspas. Mas do jeito passional que vc fala poderia muito bem ser verdade.

Não precisa ficar nervoso… Pessoal, o x@andy nunca disse que o Hibernate é maravilhoso. Isso foi conclusão precipitada minha. Ele deve achar o Hibernate razoável e só está aqui falando um monte de coisas sobre ele quer se divertir.

Podemos voltar a discussão técnica agora? Na verdade acho que melhor parar por aqui, se não alguém mais pode ficar nervoso. Eu realmente estava estranhando que esse tópico correu por quase 4 páginas sem ninguém entrar para atrapalhar.

Eu não falei que odeio o Hibernate, mas se vc tivesse concluído isso não seria mais do que um exercício primário de interpretação de texto e eu não teria ficado nervoso.

É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda!

#44

[quote=saoj][quote=x@andy]
Um monte de coisas…
[/quote]

Foi uma ironia, por isso coloquei entre aspas. Mas do jeito passional que vc fala poderia muito bem ser verdade.

Não precisa ficar nervoso… Pessoal, o x@andy nunca disse que o Hibernate é maravilhoso. Isso foi conclusão precipitada minha. Ele deve achar o Hibernate razoável e só está aqui falando um monte de coisas sobre ele quer se divertir.

Podemos voltar a discussão técnica agora? Na verdade acho que melhor parar por aqui, se não alguém mais pode ficar nervoso. Eu realmente estava estranhando que esse tópico correu por quase 4 páginas sem ninguém entrar para atrapalhar.

Eu não falei que odeio o Hibernate, mas se vc tivesse concluído isso não seria mais do que um exercício primário de interpretação de texto, certo? Lastimável!
[/quote]

Que discussão técnica? Uma discussão técnica não deve ser constituído de falácias, ironias ou ataques aos membros do mesmo! Você ultrapassou a linha do debate técnico ao utilizar de falácias e ironizar meus comentários! E qual o propósito disso? Creio que seja me irritar, coisa que não estou, de modo que eu o ataque! Isso desviaria o foco do debate e me desacretitaria.
Errei ao pensar que você estava interessado em estabelecer um debate para discutir ideias e estabelecer posições, mas esse seu comportamento é típico de um Troll! E eu não alimento Trolls!

#45

Repetindo pois acho que vc perdeu minha edição:

É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda!

#46

Esse tópico está parecendo com aquelas discussões sobre o que é melhor,
utilizar como front controller somente simples Servlets ou usar algum framework mais parrudo com mais funcionalidades como Struts, JSF, etc.

Ibatis e Mentawai são bons, mais simples, com menos funcionalidades, mas são limitados em comparação com o Hibernate.
Em um projeto nem sempre temos tempo no cronograma para implementar coisas que tem no hibernate e que não existem nesses Ibatis e Mentabean.
Por isso é melhor utilizar algo já implementado, testado e garantido, sem precisar reinventar a roda toda hora.

#47

[quote=x@ndy][quote=Markus Alemao][quote=saoj]Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.
[/quote]

Essa vai pro meu professor de banco de dados que já faz 2 bimestres que esta falando(enchendo lingüiça na verdade) sobre Hibernate, logo eu que estava tão entusiasmado com a possibilidade de escrever algo em PL/SQL …(desculpa ai o momento desabafo :slight_smile: ).

Em nome dos ditos ‘padrões de mercado’ é deixado de lado o estudo mais profundo do funcionamento de um banco de dados por essa gambiarra (bem feita …mas não deixa de ser uma gambiarra).

Enfim … excelente texto.
[/quote]
Chamar o JPA/Hibernate de gambiarra é não conhecer a importância do Mapeamento Objeto Relacional. Na verdade é não conhecer OOP. Pois se você programa orientado o objeto e não usar uma ferramenta ORM se torna praticamente impossível, pois você acaba se desviando do domínio da aplicação para desenvolver o mapeamento.
Outra coisa, usar um framework ORM, não inválida a utilização de PL/SQL. O banco de dados continua existindo e pode ser necessário criar triggers e stored procedures. Algumas tarefas devem ser feitas no banco de dados e não no sistema, pois esse é muitas vezes mais eficientes. Fora a criação das próprias tabelas, índices ,etc.[/quote]

Quanto a gambiarra:

Temos por uma lado bancos de dados, velhos, maduros,procedurais e consolidados. No outro nossas linguagens orientado a objetos (conceito ao qual rezamos todas as noites antes de dormir :D) são mundos distintos porem com certas semelhanças, dito isso, sempre fico com a impressão de que unir esses dois conceitos fica um certo cheiro estranho no ar(a dita gambiarra), indiferente se você usa ORM ou faz tudo na mão.

Quanto ao resto:

Sei que usar ORM não invalida a utilização de PL/SQL, porem o ponto que estava querendo abordar com minha colocação é que seria mais importante aprendermos sobre triggers e procedures do que um framework (alias ensinar framework é tipico de faculdade fraca) frameworks nascem e morrem mas conceitos ficam (no caso bancos de dados ficam).

Enfim a assunto já amornou, mas não tive tempo de responder antes (prova da matéria de banco de dados sobre Hibernate :frowning: )

#48

Humm… entendi sua colocação e você realmente tem razão, banco de dados relacioanais e objetos são coisas distintas realmente e a união dos dois é sempre problemática! O ideal seria utilizar um banco de dados OO ao invés de um relacional, mas eu pessoalmente nunca tive contato com um e nunca vi um sistema que fez uso de um. Só conheci casos em literatura, parece até algo fantástico e irrealizável.

Bom, se é uma cadeira de banco de dados, faz sentido realmente o aprendizado sobre os tópicos que você colocou. Mas se for uma cadeira de programação não!

#49

[quote=saoj]Banco-de-dados é algo bastante simples. Qualquer programador deveria se sentir confortável em trabalhar com SQL, índices, transações, cache, lazy loading, etc. Mas infelizmente não é isso que acontece. O tal do Hibernate virou PADRÃO de mercado. Segundo esse heavyweight framework, banco-de-dados é algo muito complicado e precisa ser abstraído. Então o que ele propõe? Sai SQL e entra HQL ou Criteria. Transações, cache, lazy loading, pode esquecer. Isso vai acontecer via mágica. E se algo não sair como esperado? Aí se vira amigo! Como vc pode ser tão burro de não configurar aquelas anotações direito? É o que eu chamo de trocar uma complexidade por outra maior/pior, com pouquíssimas vantagens.

Abaixo irei argumentar contra as vantagens oferecidas pelo Hibernate e apresentar uma alternativa muito mais simples e lightweight, para aqueles programadores que já ouviram falar em coisas "muito complexas" como um JOIN e um DAO.

bla, bla, bla…
[/quote]

Mano,

Não que eu defenda o Hibernate mais mto do que vc informou não condiz com a realidade o framework em questão.

#50

Bom argumento.

PS: Obrigado por citar minha mensagem inicial de novo.

#51

Fonte: http://stackoverflow.com/questions/825792/orm-yes-or-no

É impressionante como as pessoas não entendem que o Hibernate é o padrão do mercado e que eles deveriam estudá-lo mais para aprender como ele pode ajudar bastante o seu projeto. (Bom argumento!)

“I do recommend having some sort of abstraction to keep SQL out of your Java code, but that can be done simply with a DAO layer”. Esse cara não deve saber o que é um DAO.

Eu também pensava assim, mas depois que li a excelente explicação do x@andy sobre DAOs, aprendi que o Hibernate é muito importante, com ou sem DAO:

Falta conhecimento de padrões para esse cara do StackOverflow. Ele deveria estudar mais o Hibernate.

#52

[quote]
É muito difícil discutir com vc, porque vc é um cara muito esperto e eu não tenho capacidade de debater com vc num nível técnico. Então eu falo que vc acha o Hibernate maravilhoso para desacreditar vc. Tudo que eu falei aqui são falácias técnicas. O Hibernate á a melhor maneira de se trabalhar com Java e banco-de-dados. Como vc disse, dessa vez literalmente, o Hibernate trabalha bem em 95% dos casos e até agora vc não conheceu ninguém que não gostasse dele. Vc achou que eu fosse o primeiro herege que ia dizer que não gostava dele, mas me desculpe. Eu estava errado. O Hibernate é muito bom, eu é que não entendo das coisas direito. Vou estudar mais sobre ele. Obrigado pela sua ajuda! [/quote]
Eu estava curtindo bastante a discussão, inclusive os questionamentos de certa forma corajosos do saoj.
É uma pena que tenha baixado o nível para sarcasmos baratos.

#53
  • Tentando voltar ao tópico.

Então…este descontentamento em relação ao Hibernate e similares não é novidade, de vêz em quando surge alguem tentando construir um componente para aliviar essa…pressão vamos dizer assim. Exemplo: Persist https://github.com/rufiao/persist, existem outros mas não estou lembrando o nome no momento.

ORMs geram polemicas a todo momento, facilitam de um lado e complica do outro e gostando ou não o Hibernate é a solução mais interessante hoje, caso a opção seja adotar um ORM.

Na verdade o ponto é que o uso de banco de dados OO ainda não é uma realidade absoluta portanto qualquer coisas que seja utilizada para amenizar o impacto sempre irá dividir opiniões.

flws

#54

Seu comentário foi muito bom. Concordo com tudo que vc falou. Existem vários como o MentaBean. Persist é um. jOOQ é outro. Não sei porque o pessoal insiste em prover alternativas ao Hibernate. Como falaram aí, deve ser preguica de aprender Hibernate.

Não conhecia o Persist. Parece ser bem legal. Uma coisa que eu noto e que me parece perigoso é o seguinte:

  • O pessoal está viciado em achar que MENOS código é MELHOR. Deveriam então usar o Maker onde vc faz um sistema sem precisar escrever código nenhum. Isso é um erro na minha opinião. Se o cara quer realmente isso, então ele tem que ir programar em Ruby ou Python, que são linguagens bem mais expressivas. Por que estou falando isso? O persist tenta adivinhar o mapeamento de um objeto com o banco de dados:
// inserts a new customer (the class _Customer_ is mapped to the table _customer_ automatically)
 persist.insert(customer);

Ok, foram economizadas uma 10 linhas de código. Que maravilhoso não? Eu acho péssimo. Por que?

Eu prefiro ser EXPLICITO. Prefiro mapear o meu bean na mão e ter o controle. Se amanhã eu adiciono um novo campo no database ou uma nova propriedade no meu bean, não vou correr o risco de uma adivinhacão errada. Mesmo coisa se removo alguma coisa. Se a coisa foi mapeada explicitamente e eu removo do banco e esqueco de remover do meu mapeamento, vou ganhar um erro. Mas com essa adivinhacão nada acontece.

Então concluindo minha opinião: MENOS CÖDIGO NÃO Ë MELHOR. Não economize 10 linhas e faca o seu mapeamento na mão. A coisa fica clara, documentada e vc mantem o controle.

Programmatic Configuration:

		BeanConfig config = new BeanConfig(User.class, "Users");
		config.pk("id", DBTypes.AUTOINCREMENT);
		config.field("username", DBTypes.STRING);
		config.field("birthdate", "bd", DBTypes.DATE); // note that the database column name is different
		config.field("status", new EnumValueType(User.Status.class));
		config.field("deleted", DBTypes.BOOLEANINT);
		config.field("insertTime", "insert_time", DBTypes.TIMESTAMP).defaultToNow("insertTime");

		beanManager.addBeanConfig(config);

Fluent API:

		beanManager.bean(Post.class, "Posts")
			.pk("id", DBTypes.AUTOINCREMENT)
			.field("userId", "user_id", DBTypes.INTEGER)
			.field("title", DBTypes.STRING)
			.field("body", DBTypes.STRING)
			.field("insertTime", "insert_time", DBTypes.TIMESTAMP).defaultToNow("insertTime");
#55

[quote=saoj][quote=fantomas]
…
[/quote]

EEntão concluindo minha opinião: MENOS CÖDIGO NÃO Ë MELHOR. Não economize 10 linhas e faca o seu mapeamento na mão. A coisa fica clara, documentada e vc mantem o controle.
[/quote]

Bem acredito que hibernate, JPA etc sejam a evolução da forma de persistir, concordo que há problemas, concordo que em alguns casos há perda de desempenho, mas devo lembrar que a agilidade, flexibilidade e adaptação ao paradigma O.O.
Um exemplo de evolução: iReport que gera todo o modelo de relatório de forma quase que automática em xml, bem particularmente não vou deixar de utiliza-lo só porque alguém disse que sou preguiçoso, considerando que vou economizar tempo, ganhar agilidade e etc. O mesmo posso dizer do netbens e até mesmo do Delphi. Esta é minha forma de analisar a situação, porém respeito a opinião de todos.

att.

#56

…

#57

Não estava falando do Hibernate, e sim da configuração automática do Persist. Preguiçoso talvez não tenha sido a palavra mais adequada. Não quiz depreciar ninguém, apenas dizer que economizar 10 linhas de código pode ser ruim e talvez seja melhor configurar o mapeamento explicitamente. Editei para “Então não economize 10 linhas e faça o seu mapeamento na mão”.

#58

Já presenciei casos em que simplesmente abortaram o uso de hibernate pq 90% das pesquisas eram bem pesadas (necessitavam de uma Query bem especifica, muitas vezes até apelando pra funcoes do fabricante ex: Oracle CONNECT BY PRIOR), e o SQL gerado por ele nao atendia.

#59

Só usar uma ‘native query’,não?

#60

Só usar uma ‘native query’,não?

[/quote]

A independencia de banco de dados vai para o quiabo, se é que algúem deva ser preocupar com isso.