Talvez devessemos nos tratar como usuários do nosso próprio código/framework
e fazer com que eles sejam mais amigáveis.
Ok, o tópico fala sobre abstração de complexidade e não de quantidade de benefícios ou coisa parecida, agora se quer algo melhor que o hibernate aí vc abre um tópico só seu e aposto que vai ter gente que prefere JDBC à Hibernate. Nem tudo que te agrada agrada aos outros.
Não sabia que fazem a mesma coisa, aliás sequer citei isso quando me referi ao objetivo. Qual o principal objetivo do Java? Bem diferente do C++ e mais ainda do C# neh?
Tambem consegue fazer uma aplicação web usando todos os frameworks quanto possivel, mas isso seria tão estúpido quanto. Tambem consegue matar uma mosta com uma metralhadora mas não precisa de uma não é??
Nossa isso é totalmente relativo, não tem como falar que não funciona… à não ser que exista algum framework pronto chamado “caseiro” eu acho que se vc implementar bem vai funcionar.
Sério, e a CGLIB? É apenas mais uma das dezenas de apis que o hibernante usa?
O ow… mais uma vez vc distorceu minha resposta, em nenhum momento eu disse que polimorfismo é ridiculo, apenas falei sobre as queries polimórficas. Então oque você falou não faz o menor sentido!
Você disse que meu programa não era transacional, apenas gostaria de saber que sistema você está falando. Quanto ao commit e rollback o hibernate não inventou nada mesmo, apenas que você tinha que commitar consultas sql. rsrs
Pela última vez não estou falando de hibernate tá, sugiro que você leia o post inicial que apenas sita um exemplo do hibernate além do mais tudo que é feito com ele é possivel fazer com java -mesmo que vc não acredite- caso contrário ele teria sido desenvolvido em outra linguagem.
o assunto em questão continua sendo ABSTRAÇÃO DE COMPLEXIDADE VS. REINVENTAR A RODA
[quote=fabioissamu]Talvez devessemos nos tratar como usuários do nosso próprio código/framework
e fazer com que eles sejam mais amigáveis.
[/quote]
Esse era o tipo de resposta que eu queria nesse post! Mas o pessoal gosta de hibernate.
Falo exatamente nisso, coisas amigáveis!!
“Reinventar a roda” é uma expressão que pode significar qualquer coisa de ruim, onde não se precisa pensar muito. É a mesma coisa que os esquerdistas radicais fazem ao falar a palavra “privatização”: não se pensa muito, apenas serve pra dizer que é ruim.
Abstrair criando um novo idioma por cima (como o Hibernate, que faz com que tratamos os dados relacionais como se fossem orientados a objetos) não é errado. O causa do problema do “configuration hell” não é a abstração em si, mas como foi feita essa abstração.
Não vejo em Java nenhum tipo tratamento de configuração muito bom, nem xml, anotations ou no próprio código (apesar de, particularmente, dar preferência a anotations sobre os demais). O que considero muito bom mesmo é o que o ActiveRecord faz usando o Ruby. Aquele “validate_presence_of”, por exemplo, parece mágica, mas é só um método de classe de ActiveRecord::Base, chamado apenas uma vez e que irá alterar o comportamento da classe, e ainda por cima, sem necessidade de container. Mas é pena que é um comportamento difícil de se reproduzir no Java, pelo menos não tão facilmente.
Justifica sim. A HQL é uma forma de abstrair o SQL nativo. Isso é importante num mecanismo de abstração como o Hibernate que tem que produzir SQL ligeiramente diferente conforme o banco de dados.
Por outro lado o HQL é uma implementação do padrão Intrepreter. Este padrão permite que seja incluidas funcionalidades de forma desacoplada do SQL subjacente. Em particular trabalhar com classe e objetos e não com tabelas e linhas.
O único problema do HQL é que não é padrão (no sentido de que é suportando por um produto e não como o SQL que é por uma especificação). Mas isto é natural. A necessidade do HQL existir é maior ( porque advém directamente do objetivo do Hibernate) que a necessidade de ser padronizado ( coisa que o SQL tb não é 100%)
[quote=saoj]Quando vc vai a um restaurante e já na entrada a comida está estragada, então eu prefiro nem ficar para o prato principal. O “Getting Started” do Hibernate, isso mesmo, o HelloHibernate, utiliza transação para um select. Veja o exemplo que vc postou:
private List listEvents() {
Session session = HibernateUtil.getSessionFactory().getCurrentSession();
session.beginTransaction();
List result = session.createQuery("from Event").list();
session.getTransaction().commit();
return result;
}Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.
[/quote]
Serio Sergio, voce precisa mesmo pesquisar mais antes de falar essas coisas. Em especial do hibernate, que uma enorme quantidade de casos muita gente corrigiu coisas que voce falava que nao dava pra fazer, ou que seria complicado.
Voce acha mesmo que nao ha uma razao pela qual um programador super reconhecido fez uma transacao em volta de um select? Se acha que nao, pesquise. quer ja mastigado? va ao google e procure por “selects query inside function must read commited data”. Ha sim uma diferenca, e muito significativa dependendo do seu commit option. Alias, li por aqui que voce ja trabalhou em sistemas grandes com muita concorrencia, e é nesses casos que costumam aparecer dirty reads, phantom reads, etc… Ja que quem esta certo nesse caso é o hibernate, a comida estragada nao estaria no mentabeans, que esta ensinando select sem transacao?
Sua declaracao é: “se a documentacao do hibernate mostra um exemplo com boas praticas que eu nao entendi , logo temos um problema”. Que problema? Que as pessoas vao ter de entender o porque daquilo? Explique o problema, nao sei do que voce esta falando.
Outra afirmacaosu , falando sobre a configuracao programatica ser praticamente inexistente. Se ela existe, como ela é praticamente inexistente? Alias, antigamente voce declarava que nao existia, sem saber, e nem mesmo procurar!
Fico chateado em ouvir declaracoes como essa a respeite de um framework como o hibernate, que sem duvida é hoje em dia o framework de mais sucesso do mundo, em termos de qualidade, confiabilidade, performance, documentacao, etc. Se o hibernate é ruim, o que é bom?
[quote=Paulo Silveira][quote=saoj]
Não faz qualquer sentido ter um commit para um select, mas se a própria documentação do Hibernate incentiva isso então temos um problema.
[/quote]
Serio Sergio, voce precisa mesmo pesquisar mais antes de falar essas coisas. Em especial do hibernate, que uma enorme quantidade de casos muita gente corrigiu coisas que voce falava que nao dava pra fazer, ou que seria complicado.
Voce acha mesmo que nao ha uma razao pela qual um programador super reconhecido fez uma transacao em volta de um select? Se acha que nao, pesquise. quer ja mastigado? va ao google e procure por "selects query inside function must read commited data". Ha sim uma diferenca, e muito significativa dependendo do seu commit option. Alias, li por aqui que voce ja trabalhou em sistemas grandes com muita concorrencia, e é nesses casos que costumam aparecer dirty reads, phantom reads, etc…
Sua declaracao é: "se a documentacao do hibernate mostra um exemplo com boas praticas que eu nao entendi , logo temos um problema". Que problema? Que as pessoas vao ter de entender o porque daquilo? Explique o problema, nao sei do que voce esta falando.
Outra afirmacaosu , falando sobre a configuracao programatica ser praticamente inexistente. Se ela existe, como ela é praticamente inexistente? Alias, antigamente voce declarava que nao existia, sem saber, e nem mesmo procurar!
Fico chateado em ouvir declaracoes como essa a respeite de um framework como o hibernate, que sem duvida é hoje em dia o framework de mais sucesso do mundo, em termos de qualidade, confiabilidade, performance, documentacao, etc. Se o hibernate é ruim, o que é bom?[/quote]
Paulo, o próprio sergio falou aqui que quem usa hibernate não está errado, não é uma crítica ao hibernate e sinceramente se eu falei alguma besteira aqui agradeço se me corrigirem tambem pois não sei tudo de hibernate.
A questão que eu estou falando é com relação ao Reinventar a roda, ou seja se um cara pegasse todos os códigos do hibernate os estudasse e fosse desenvolver um framework o "Cópia de hibernate(1)" ele o faria diferente, talvez melhor, talvez pior, mas não estaria inventando a roda, estaria criando uma nova opção, vocês que usam hibernate devem conhecer algum defeito nele e é disso que eu estou falando, talvez fosse inviável fazer aquela alteração que vc tanto queria mas desenvolver outro com essa alteração não seria inviável pois o melhoraria muito.
E isso não é só com hibernate, isso é com a maioria dos frameworks, o Struts por exemplo, entenda, EXEMPLO, poderia ter desenvolvido seu próprio controler ao invés de usar o xwork, isso poderia resolver outros problemas como o fato de eu ter que ter um xwork-conversion.xml dentro do meu projeto em struts, não estou falando em não usar apis, estou falando em não ficar amontuando framework em cima de framework e gerando coisas escabrosas… Daqui a pouco vai ter gente desenvolvendo frameworks em cima do struts para abstrair a complexidade do mesmo aí teremos xwork > struts > Novo Framework e vai saber até aonde iria, ou até mesmo do hibernate.
[]'s
Oi Volnei
Respondendo suas perguntas
- O Hibernate segue a JPA se voce quiser usa-lo dessa maneira.
- O Rod Johnson nao esta participando a toa como um dos lideres da especificacao do Java EE 6.0. Spring vai acabar implementando alguma especificacao, essa é um aposta minha pessoal.
- Quem usa Oracle e sabe que nao vai mudar de bancos usaria o Hibernate para gerenciar o estado dos objetos persistentes, e nao apenas esconder as queries sql. Gerenciar estado é saber a hora que o objeto foi modificado, a hora de fazer o update, a hora de verificar mudanca concorrente, a hora de buscar mais dados no banco, etc. Entao voce deixa o gerenciamento de estado na mao do hibernate, que é algo que da muito trabalho quando temos envolvidas muitas entidades.
[quote=Paulo Silveira]
Respondendo suas perguntas
- O Hibernate segue a JPA se voce quiser usa-lo dessa maneira.
- O Rod johnson nao esta participando a toa como um dos lideres da spec do Java EE 6.0. Spring vai acabar implementando alguma spec, minha aposta pessoal.
- QUem usa Oracle e sabe que nao vai mudar de bancos usaria o Hibernate para gerenciar o estado dos objetos persistentes, e nao apenas esconder as queries sql. Gerenciar estado é saber a hora que o objeto foi modificado, a hora de fazer o update, a hora de verificar mudanca concorrente, a hora de buscar mais dados no banco, etc. Entao voce deixa o gerenciamento de estado na mao do hibernate, que é algo que da muito trabalho quando temos envolvidas muitas entidades.[/quote]
Certo Paulo, mas não justifica ao meu ver, por exemplo usar o hibernate num projeto com 10 entidades. Mas oque eu estou querendo dizer é oque está no meu ultimo post acima deste…
Serio Paulo. Não precisa ficar nervoso. Não conconrda com os meus argumentos, então basta colocar os seus. Essa revolta toda é desnecessária e não ajuda em nada ao debate. Toda vez que eu falar uma coisa que vc considera errado, fique a vontade para contra argumentar de maneira educada. Quem ganha com isso é o forum.
Minha especialidade não é banco de dados, nem ORM. O tópico também não é sobre isso, como o autor já enfatizou bastante. Mas gostaria de pedir a sua autorização para tentar dar minha opinião, posso? Se eu falar uma coisa errada ou que vc não concorde me desculpe ok?
Vc está falando de temas avançados: Dirty read e phanton read. Eu prefiro pensar apenas como o Oracle e outros bancos de dados de primeira linha pensam: “Leituras nunca são bloqueadas e nunca bloqueiam ninguém. Escritas bloqueiam apenas outras escritas.” Eu realmente acho um disperdício de recursos e simplicidade querer colocar uma transação ao redor de uma leitura por default pra tudo porque vc está com medo do isolation level do seu banco. Já vi muitas pessoas usando o hibernate sem transaction para a select e o sistema deles funciona muito bem.
Calma, Paulo. Não trabalho com concorrencia. (Onde vc leu isso?) Trabalho com NIO. Tudo single threaded. Já trabalhei com concorrencia mas a nível de thread e não a nível de banco de dados. Não sou DBA Oracle.
E sobre o select, então quando vc trabalha com JDBC vc abre uma transação antes de cada select que vc dá? Eu realmente acredito que o default deva ser “não usar transações para selects”. Agora se vc pensa diferente porque vc está com medo dos phanton reads, me desculpe.
Vou repetir minhas palavras aqui: " E vc não colocou a parte mais importante que é a configuração disso tudo via annotations ou xml. (Ok, ele suporta configuração programática, mas ninguém usa, não é recomendado pelos autores e não há documentação clara, então é próximo de inexistente)"
Vc está vendo o que quer ver ou lendo o que quer ler. Eu nenhum momento eu falei que era ruim, muito pelo contrário. A minha crítica foi que para um grande número de situações mais simples ele pode se tornar uma bazooka para matar uma mosca.
Se vc ficou chateado, me desculpe. Vou ajudar o autor do tópico: ESSE TÓPICO NÃO É SOBRE O DOGMA HIBERNATE! Assim realmente fica difícil qualquer discussão mais interessante nesse forum…
Será que agora alguem vai responder?? Parece que só se fala em Hibernate aqui.
To começando achar que o java roda em cima do hibernate… 
Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.
Sinceramente não to visualizando o que tem de complexo nisto.
[quote=emerleite]Eu acho que em sistemas bem simples o hibernate ajuda pra caramba. As vezes não preciso nem me preoculpar com coisas mais cascudas. Simplesmente uso @Entity as vezes @Transient e fica tudo limpinho e bem facil. Para CRUDS então vira algo trivial.
Sinceramente não to visualizando o que tem de complexo nisto.[/quote]
Ok, só que como citado XXX vezes esse tópico [size=24]NÃO É SOBRE HIBERNATE![/size]
O problema é que você começou esse tópico criticando o Hibernate. Aí o saoj continuou, dando exemplo do MentaBean, e você concordou, aí apareceu a galera que conhece e usa o Hibernate pra dar as opiniões, você ficou irritado e deu no que deu.
Ao meu ver, você tomou a opinião do pcalcado como pessoal… Ele estava só querendo continuar a discussão, contraargumentando o que você começou. O saoj também se irritou com o que o Paulo disse, mas nem vi essas ofensas todas.
Por favor, não estou querendo continuar o flame. Não quis ofender ninguém com esse post.
Primeiramente que está irritado aqui acho que não sou eu… mas se as pessoas tivessem um pingo de noção não colocariam mensagens que não colaboram com o tema proposto, a exemplo da sua!
Cadê a critica??
Quem se atreve a negar isso?
Acho que vc deve ter confundido o tópico amigo!
Pois é, confirmando o que eu disse, você está visivelmente irritado e não está em condições de discutir nada.
Vou seguir o exemplo dos que tentaram conversar com você e não conseguiram, e vou deixar de responder a esse tópico.
Acho que Hibernate foi um exemplo infeliz. Não considero ele um dogma da igreja, mas concordo que ele revolucionou ORM pra Java e resolve desde o mais simples ao mais complexo. A questão do commit para select, que segundo o Paulo pode afinal ter um motivo, sempre me revoltou um pouco, por isso que eu acabei me empolgando na resposta.
Uma coisa é um Hibernate da vida outra coisa é um simples gerador de queries. Para quem vai trabalhar com JDBC puro se torna essencial um gerador de queries para ajudar o cara nas tarefas básicas. É apenas pra isso que serve o MentaBean, para ajudar o pobre-coitado que não sabe ou não quer usar Hibernate. Se ele já sabe então melhor ainda pra todo mundo!
Acho que o que o autor queria falar, e eu concordei, é que toda abstração é sempre bem vinda e isso não deve ser considerado reinvenção de roda. Pra que inventar o carro se já tinha charrete? (Não vai pensar que o primeiro carro andava a 80 km por hora, pois nem rua tinha!)
[quote=tnaires]Pois é, confirmando o que eu disse, você está visivelmente irritado e não está em condições de discutir nada.
Vou seguir o exemplo dos que tentaram conversar com você e não conseguiram, e vou deixar de responder a esse tópico.[/quote]
Se não tem argumentos o melhor que você faz realmente é ficar assistindo… e se eu realmente estou errado me mostre aonde.
Não há nada pra mostrar, as mensagens estão todas aí. Basta lê-las (a não ser, claro, que você as edite).
Já o Sérgio, em sua resposta, se mostrou bem mais maduro e equilibrado.
Obrigado pelo respeito.