Persistir objetos já é um problema resolvido, basta usar banco de dados NoSQL. O autor não esta falando de alternativas para persistir objetos, e sim que objetos não são adequados para representar dados de natureza relacional.
O argumento do autor é que objetos são uma abstração pobre para dados de natureza relacional. E toda essa customização (para o autor é complexidade) existente nos frameworks ORM são uma prova disso.
Acredito que uma coisa todos vão concordar, um modelo OO é diferente de um modelo relacional, o que acontece é que temos a necessidade de usar um meio de armazenamento relacional para colocar dados providos de modelos OO, ai é que mora o problema. Não importa o qual seja o meio, ele é um fazedor de gambiarras para minimizar a diferença desses dois mundos.
Óbvio que o mais correto seria não utilizar meios relacionais para armazenar os dados de um sistema OO, mas em 90% dos casos não existe essa opção, por necessidades técnicas, por preconceito, por falta de conhecimento das soluções.
Com o avanço dos ORMs, é claro que ficou muito menor esse gap e muito mais simples de se trabalhar, por isso muito gente ainda precisa usar um banco relacional, porque não ve mais complexidade em trabalhar com eles em seus projetos OO. Agora que em algum ponto, seja o adapter, seja o framework ORM, alguém faz uma gambeta pra esses dois modelos se intenderem, tanto que hoje ainda se desenvolve igual a 1970, cria-se o bando relacional e “importa-o” para os modelos OO do projeto.
[]s
Só pra ter certeza, vc foi irônico aqui né? 
[quote=Jesuino Master]
Aplicações que crio hoje são com Hibernate por default, JDBC puro só se tiver poucas entidades. Por que:
- Código mais limpo;
- facilidade de manutenção;
- várias coisas que não precisarei fazer na mão (cache, queries, controle de transação, logging). [/quote]
Usar JDBC puro com poucas entidades não é tão ruim. O problema é que para criar um sistema OO não-trivial com poucas entidades requer anos de experiência com modelagem OO. Não estou falando que é seu caso, mas estou cansado de ver gente que acabou de ler o resumo de DDD e começa se achar expert, que descobriu A UNICA MANEIRA CORRETA de desenvolver sistemas OO. Mas OO não é sobre separar objetos em camadas, e sim reduzir complexidade. ORM resolve o primeiro porcamente, e é um desastre no segundo.
Como disseram anteriormente…
A aplicação é OO e o banco de dados é relacional…
Qualquer solução para ligar os dois mundos é um ORM… mesmo que seja um loop pegando um resultset e preenchendo os objetos na mão…
O autor do artigo não está criticando ORM de uma forma geral e sim implementações específicas… Exemplo: Ele diz que a documentação mostra a query da ferramenta mas não mostra a query original SQL… Isso é um problema na documentação da ferramenta e não do conceito ORM…
O que imagino que faça a confusão no artigo é que ele mostra várias limitações das ferramentas ORM e elas realmente existem, como sendo ORM. Uma coisa é uma critica as ferramentas, outra é critca a ORM. O autor não soube separar as duas coisas. No meu ver o autor tem pouca experiência sobre ORM.
Sobre os problemas de ORM que ele cita…
Inadequate abstraction
Ele diz que a abstração ORM não é adequada e que por isso, você acaba tendo que conhecer de SQL. Podemos ter níveis de abstração, onde nem 100% dos problemas são abstraídos. Qualquer solução de qualquer problema que abstraia 100% é utópico. Abstrações em algum momento falham. E uma abstração que não leva em consideração isso, é falha. Por isso as ferramentas ORM não criam um outro mundo virtual para se trabalhar com objetos, porque (1) seria extremamente difícil de implementar, (2) estaria sujeito a falhas e (3) poderia ter uma performance inaceitável.
O caso, é que temos um problema que é mapear objetos em tabelas relacionais, as ferramentas ORM ajudam a resolver esse problema. O atual estado da arte exige que você conheça de SQL mas isso não significa uma abstração ruim.
Ele também diz que você tem que aprender duas coisas, primeiro o SQL e depois o ORM. Mas veja, se você fizer uma aplicação você terá que entender das duas coisas, porque você precisa mapear os seus objetos nas tabelas. Então já que terá que entender alguma coisa sobre isso, estude uma ferramenta que a longo prazo você terá enormes vantagens. Eu considero que a quantidade de informação necessária para se conseguir trabalhar numa aplicação ORM é pequena em relação aos ganhos. Tudo é questão de custo beneficio. O custo de se aprender o hibernate (por exemplo) é compensado por seus benefícios? Na minha opnião sim.
Ele fala também sobre JOINS. Que apenas no inicio do projeto você consegue se sustentar sem criar joins e que num futuro você terá que quebrar a sua abstração. Bem, talvez ele desconheça que é possível fazer joins em ORMs (hibernate por ex). Eu inclusive não uso Lazy Loading, faço joins nas queries. Mas se precisar de um projeto que saia rápido e não tem problemas de performance, porque não usar o Lazy Loading?
Incorrect abstraction
Aqui ele já começa a entrar em outro assunto… Sobre se você deve utilizar NoSQL ou banco de dados relacionais. Acho que até foge um pouco da discução original.
Death by a thousand queries
Aqui é o problema do Lazy Loading e a utilização de várias queries para puxar resutlados. Além disso ele menciona que você precisa puxar uma tabela com 30 colunas se precisar de apenas 3 delas. Para o problema do Lazy Loading, existem joins nas ferramentas ORM (como hibernate), e você consegue expressar suas queries até determinado nível. Se for extremamente complexa, você tem a opcão do SQL. Na minha experiencia uma porcentagem muito pequena das queries são tão complexas que será necessário fazer o SQL. Para o problema de puxar apenas algumas colunas, bem o hibernate por exemplo não permite… Mas o framework que utilizo sim… então é apenas uma limitação da ferramenta e não do conceito de ORM.
Alternativas propostas
If your data is objects, stop using a relational database. (Nem comentarei essa frase porque acho que não faz o menor sentido. Simplesmente ele ignora todas as vantagens de um banco de dados relacional)
Use SQL in the Model. E faça na mão o que uma ferramenta ORM poderia fazer por você. (Para mim é uma solução ruim…)
Bem… resumindo… na minha visão o autor confundiu as limitações de ferramentas com ORM. Só porque uma abstração não abstrai 100% do problema não quer dizer que seja uma abstração ruim. Não considero um artigo com informações ou argumentos válidos. Acho que o autor necessita organizar as idéias sobre o que é o que, antes de escrever uma crítica dessa natureza.
Concordo com o Luiz, ORM na maioria das situações é bem mais produtivo. É uma vergonha o Java a tantos anos no mercado e ainda era tão primitivo pra acessar banco de dados.
Mas nas situações mais complexas, ele é um problema mesmo, aí tem de apelar pra uma solução mista.
Post favoritado.
Mais uma vez eu falo:depende do projeto!Dizer que o hibernate deve ser usado em tudo, é forçar a barra, apesar da grande mão na roda que ele é.
Não sei que tipos de projeto você está acostumado a pegar, nem para quais empresas você trabalha/trabalhou, nem suas necessidades, mas te digo, tem muitas empresas por aí que o hibernate te geraria mais problemas do que solução.Quer um exemplo?
Todo mundo aí falando da facilidade do Hibernate gerar queries e relacionamentos, e eu pergunto:
Nas empresas onde vocês trabalham vocês podem ir criando Views,Sequences, Triggers a torto e a direito?
Trabalho com o setor elétrico há 6 anos, e te digo:Em muitas dessas empresas, se vc criar uma View, e o DBA não tiver te autorizado, haverá “hell to pay” para o programador.
Uma das piores coisas que eu passo nesse setor, é justamente a falta de coesão dentro da TI dessas empresas.Muitas coisas demoram uma eternidade, campos duplicados em várias tabelas, campos/views/triggers necessárias faltando e coisas absurdas que dependem de “decisão política” para o projeto andar, de alguém que pede a secretária para ligar o computador para ler o email.
Certamente que não, mas se for algo cotidiano(digamos semanalmente) e alguém mostra uma diferença dessas num processo, te aviso:Você pagará caro, não importa quão thread-safe, OO e segura será sua app.
Eu não devo ter tido muita sorte, mas com grandes empresas, só mente UMA vez, pude escolher TUDO o que eu queria dentro de um projeto(todas as etapas da prototipação ao produto final).
Na maioria das vezes, acho que essa é a que mais vale, até porque muitos sistemas já são uma “solução mista” dentro de outra… :roll:
[quote=Ironlynx]Nas empresas onde vocês trabalham vocês podem ir criando Views,Sequences, Triggers a torto e a direito?
[/quote]
Acho que vc esta enquadrado nos casos específicos que eu mencionei… governo, todo tipo de estatal, onde só se usa velharias “homologadas” e não se pode nada. Já trabalhei em bancos, Petrobras da vida e existe mesmo esse tipo de coisa, mas mesmo assim, colocar o suporte ao Hibernate ainda é meio que padrão, o que e onde usá-lo no projeto é que é mais estudado com cautela, exatamente por essas coisas que vc citou.
Se é possível fazer 30% que seja com ORM, sem prejudicar a performance, por que não fazer? O restante pode-se fazer com SQL puro do mesmo jeito. Mas acho que a maioria dos novos projetos web iniciados hoje mundo a fora não tem esse tio de restrição cultural tão forte como nessas empresas.
[]s
[quote=ccarrara]Conheço um caso onde o desenvolvedor subestimou a amplitude do projeto e começou a desenvolver com JDBC. No meio do projeto comecei a acompanhá-lo no desenvolvimento e ele me falava: “se tivesse usado Hibernate seria tudo mais simples”. Mas o que eu observei foi que a todo momento ele precisava revisar querys, seja por mudança nos requisitos ou seja por bug mesmo. E ele tinha certa dificuldade com SQL, joins e até mesmo a modelagem do banco tinham alguns probleminhas que precisavam de gambiarras…
Enfim, o que vocês acham, ORM seria mais indicado para projetos de maior ou menor porte? Isso depende?[/quote]
Na verdade, o ideal é que alguém com bons conhecimentos de Base de Dados desenhe e/ou implemente as instruções SQL quando vai trabalhar sem uma ferramenta ORM. Especialmente no caso de ocorrência de diversas mudanças.
Aliás, prefira ter um DBA por perto mesmo utilizando ORM. É ele que vai resolver teus problemas se você errar ao modelar a base.