Sobre ORM

GUJ Master Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

Cheguei a conclusão de que o "sucesso" de ferramentas como o Hibernate se deve exclusivamente a incapacidade dos desenvolvedores de aprender modelagem de dados e SQL. O "sucesso" aí é relativo, me refiro a noção de que isso é necessário, não a quantidade de projetos mundo afora, pois, para dizer a verdade, não tenho visto muitos.

Uma boa parte dos desenvolvedores:

- jamais ouviu falar de "formas normais";
- não sabe como e nem quando usar chave estrangeira;
- quando conhece "chave estrangeira" ele não acredita na sua utilidade;
- subquery, join, procedure, function...? Vixi. Aí você já está falando grego.

Assim qualquer coisa é difícil. Como escrever montes de XML pra mapping é mais fácil do que um simples comando SQL? Como adicionar dependência do seu projeto em um aplicativo de terceiros é mais fácil do que pegar um bean com os dados em uma única linha?

SQL é a melhor tecnologia que existe para esse tipo de manipulação de dados, criar uma forma "OO" é no mínimo reinventar a roda.

O pior são os que são contra "chave estrangeira". É a mesma coisa que ser contra cinto de segurança.

Nossa meu...rs Quem nunca ouviu falar de normalização é dose...

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

Tecnoage wrote:Nossa meu...rs Quem nunca ouviu falar de normalização é dose...

Muita gente nem chegou a esquentar os bancos de alguma faculdade - e é por isso que você vê coisas bizarras como tabelas com 100 campos do tipo "endereco001", "endereco002", ... "endereco099", "endereco100" - isso porque o cara nem tem idéia de o que é um relacionamento.

Mas o Hibernate não é usado somente por quem não conhece nada de SQL. Acho legal o fato de não precisar reescrever queries, o aumento de produtividade, a independência do SGBD, etc. Tem ainda os casos de quem sabe mas não gosta de ficar escrevendo querie.
Ou você acha que um sujeito que não conhece normalização, join, etc vai conseguir fazer uma ORM boa?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

IMHO para trabalhar com Hibernate acredito que conceitos de SQL são fundamentais, thiagosc. Se o cara não sabe isso ele é um programador ruim com ou sem hibernate.

Não somente de SQL, mas do modelo Relacional como um todo, uma vez que este é utilizado na grande maioria dos projetos.

Pessoal, vamos dar um tempo. Alimentar troll?

Ferramentas não fazem milagres. Desenvolvedores assim serão ruins com ou sem ferramentas ORM.

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Eu acho que o sucesso se deve a enorme improdutividade de se trabalhar com JDBC puro.

Não acho também que todos devam saber o que é uma Stored Procedure, um trigger e tal.. mas...

não saber o que é chave estrangeira já é demais....

felipec wrote:Eu acho que o sucesso se deve a enorme improdutividade de se trabalhar com JDBC puro.

Não acho também que todos devam saber o que é uma Stored Procedure, um trigger e tal.. mas...

não saber o que é chave estrangeira já é demais....

Eu discordo um pouquinho... Na minha opinião TODOS os desenvolvedores deveriam sabem bem banco de dados relacionais. Há coisas ( e onde trabalho MUITAS coisas) que não são passíveis de serem manipuladas pelo hibernate, por exemplo. Tem que ser Stored Procedures, triggers e tal.

felipec wrote:não saber o que é chave estrangeira já é demais....

Os POG Certified só sabem fazer um tipo de select:

Eventualmente, conheci alguns (utilizaram o mesmo código acima, em vários trechos) que estavam xingando a performance de uma base MySQL. Apenas pedi um EXPLAIN e criei um índice. E mandei eles procurarem entender como um RDBMS funcionava.

Lembrei que, em outro forum, um cara tentava criar uma tabela com o nome, por exemplo "João da Silva" e, nessa tabela, ele colocaria dados de um compra, por exemplo.

É claro que TODO MUNDO tentou faze-lo desistir dessa abordagem, inclusive eu me dei ao trabalho de mostrar uma forma de trabalhar com 3 tabelinhas, PK-FK, essas coisas, mas foi em vão.

Cheguei a conclusão q isso é programação na força bruta.

felipec wrote:Eu acho que o sucesso se deve a enorme improdutividade de se trabalhar com JDBC puro.

Eu gosto do JDBC puro. Pra questões de produtividade desenvolvi ferramentas próprias que geram meu código de acordo com a estrutura do banco, de modo que grande parte do acesso no JDBC ficam nas minhas classes base, fazendo que eu me preocupe pouco com código SQL (a não ser em relatórios). Ficou bem legal e rápido. O Hibernate estava meio lerdo na execução.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Thiagosc wrote:Cheguei a conclusão de que o "sucesso" de ferramentas como o Hibernate se deve exclusivamente a incapacidade dos desenvolvedores de aprender modelagem de dados e SQL. O "sucesso" aí é relativo, me refiro a noção de que isso é necessário, não a quantidade de projetos mundo afora, pois, para dizer a verdade, não tenho visto muitos.

O sucesso de ferramentas como o hibernate está no fato delas proverem uma abstração OO para a persistência/recuperação de Objetos. Ou seja, ele usa objetos para persistir/recuperar objetos.

Uma boa parte dos desenvolvedores:

- jamais ouviu falar de "formas normais";
- não sabe como e nem quando usar chave estrangeira;
- quando conhece "chave estrangeira" ele não acredita na sua utilidade;
- subquery, join, procedure, function...? Vixi. Aí você já está falando grego.

A beleza de usar uma linguagem OO como Java é que não é necessário saber essas coisas. Vc tem que entender que para quem usa OO o banco é apenas um sistema de arquivamento complexo e util para persistir e encontrar informação. Não é um ambiente de programação (logo, procedure e function são inuteis* ) , não é um sistema de validação de regras (logo trigger , chave estrangeira, referencia etc, são inuteis*) e não é um mecanismo formal. i.e. o objetivo é simplificar o mapeamento dos objetos para o banco e não do banco para os objetos; logo as formas normais são usada até onde forem uteis e join é uma coisa inútil*.

* Inutil do ponto de vista da aplicação. Do ponto de vista estrutural de quem faz um framework de persistência, podem ser ferramentas importantes. O join pode ser usado, mas procudures e functions criam um vendor-lockin que é um problema muito grave do ponto de vista de quem escolher Java. Chave estrangeire/ referencias é bom até que começa a impedir o framework de persistencia de fazer as coisas da forma mais simples. Porque eu preciso integridade referencial explicita se o framework OO me garante essa integridade de forma implicita ? Pois é, não preciso.
Claro que posso usar , e às vezes é necessário usar os mecanismo do banco, mas 99%das vezes não é isso que desejamos fazer.

Assim qualquer coisa é difícil. Como escrever montes de XML pra mapping é mais fácil do que um simples comando SQL?

Esta é fácil. Porque o XML me garante que não vou ficar preso ao dialeto de determinado banco. Além de que o XML pode ser construido por ferramentas que se alimentam de outros dados, como diagrama ER.

Como adicionar dependência do seu projeto em um aplicativo de terceiros é mais fácil do que pegar um bean com os dados em uma única linha?

Como adicionar ao seu projeto dependência de um banco de dados especifico é mais fácil do que pegar um bean com um objeto que abstrai o SQL e seus dialetos de forma automática?

Como fazer refactoring de objetos é mais dificil que fazer manipulação de strings SQL ?

SQL é a melhor tecnologia que existe para esse tipo de manipulação de dados, criar uma forma "OO" é no mínimo reinventar a roda.

SQL - Structured Query Language - é uma linguagem independente da tecnologia de banco. Tanto é que ela foi adaptada para objetos (HQL, EQL ,etc)
O que faz com que vc ache que SQL é só para banco de dados são os malditos dialetos criados pelos vendedores de RMDS. Ok, HQL tb é um dialecto maltido, mas o ponto é que SQL é independente e se adapta à tecnologia subjacente. Moral da historia, é possivel continuar usando SQL
de forma OO sem nunca saber que existe um banco de dados rodando.
E esta é que é a vantagem de OO: Encapsulamento.

Thiagosc wrote:

Uma boa parte dos desenvolvedores:

- jamais ouviu falar de "formas normais";
- não sabe como e nem quando usar chave estrangeira;
- quando conhece "chave estrangeira" ele não acredita na sua utilidade;
- subquery, join, procedure, function...? Vixi. Aí você já está falando grego.

Ué, usando Hibernate ou não, o desenvolvedor também tem que ter esses conceitos. O uso de uma ferramenta ORM não exclui a necessidade de conhecer chave estrangeira, join, etc.

Thiagosc wrote:
Assim qualquer coisa é difícil. Como escrever montes de XML pra mapping é mais fácil do que um simples comando SQL? Como adicionar dependência do seu projeto em um aplicativo de terceiros é mais fácil do que pegar um bean com os dados em uma única linha?

O que é mais fácil para você:

Ou:

E nem vou entrar no mérido de selects, joins, delete, etc.

e note, usando Hibernate já ganha "de brinde", de forma bem transparente, cache, pool de conexões, serviço de indexação, validação...

Enfim, (mais) um ponto a menos para você

Notícias, artigos e o maior fórum brasileiro sobre Java