ORM é um anti-pattern

Eu tive um professor que falava isso
Ele chamava ORM de bacalhau da OO

O que seria do mundo se não existisse a critica … rs

Tem gente que gosta de caçar pelo em ovo … é isso que eu acho =]

Essa afirmação me lembra os comentaristas de futebol: eles sempre sabem o que está errado no time, o que deveria ser feito para reverter o placar. Porém, quando viram treinadores(dada a notória capacidade de análise), a coisa muda de figura.

Eu compartilho da opinião do autor do post no blog.
Não gosto de ORM.
Eles são úteis para projetos simples, mas em projetos mais complexos eu não consigo gostar deles. Mais atrapalham que ajudam.
Para projetos assim, eu procuro correr para uma das duas seguintes direções: relacional ou objetos.
ORM é uma gambiarra para que nós imaginemos os nossos registros como objetos, mas ele peca em justamente incentivar o culto ao banco relacional.
Eu só vejo ORM como um pattern quando existe base de dados legada, onde a transferência dos dados para uma base não-relacional custasse muito caro ou fosse realmente impraticável.
Fora esses casos, eu vejo ORM como um anti-pattern.

Acho que o problema principal é de quem usa ORM para TUDO, sem discriminar o que fará seu uso.A maioria dos programadores hoje se tornaram Lazy.Lembro de um amigo que quando leu o livro de Patterns, saia encaixando tudo quanto é padrão aonde dava.Ele não esperava para ver a necessidade, ele encontrava uma. :shock:
Padrões atendem a uma necessidade, o mesmo com os ORM´s da vida.Tem programador por aí, dizendo que ORM substitui DBA, depois não entende pq ninguém pega o gargalo da aplicação… :roll:
Posso dar um real exemplo:Fiz uma importação aqui(de texto usando JDBC-Oracle) de quase 50mil linhas e dezenas de campos.Demora 1minuto, mesmo com verificações se um campo está vazio, colocar 0 num dado local e etc.Não gostaria nem de imaginar quanto tempo demoraria se eu usasse um ORM, sendo que no meu caso, velocidade é fundamental.

Ironlynx:

Posso dar um real exemplo:Fiz uma importação aqui(de texto usando JDBC-Oracle) de quase 50mil linhas e dezenas de campos.Demora 1minuto, mesmo com verificações se um campo está vazio, colocar 0 num dado local e etc.Não gostaria nem de imaginar quanto tempo demoraria se eu usasse um ORM, sendo que no meu caso, velocidade é fundamental.

[]s

É polêmico mesmo, na maioria das situações ajuda muito na produtividade, principalmente no Java onde programar JDBC puro é braçal. Mas em outras situações, ele exige muito mais complicação onde um sql relacional comum resolveria fácil, fácil.

Na minha opinião, ele ainda compensa, independente de ser anti-pattern ou não. Mas algumas coisas nele gostaria que fossem diferentes.

Não tô com nenhuma ferramenta ORM aqui, mas um amigo comparou uma importação de 100mil linhas(também JDBC-Oracle) e a diferença foi de quase 3 minutos(a mais) em relação ao JDBC.Se tinha N level cache otimizado, esses detalhes ou não, não sei dizer.

Também acho.O problema é que muitos programadores fazem uma cgd* O-R, deixam muitos DBA´s fulos da vida, que acabam dizendo que todo programador java não sabe montar relacionamentos.A ânsia pela velocidade de codar, faz alguns não pensarem antes de montar as aplicações. :roll:

Ah! É isso mesmo. Muitos programadores acham que conseguem montar o banco só usando objeos, sem pensar num nível de banco mesmo (parece que têm medo de SQL). É aqui que mora um dos perigos.

Ah! É isso mesmo. Muitos programadores acham que conseguem montar o banco só usando objeos, sem pensar num nível de banco mesmo (parece que têm medo de SQL). É aqui que mora um dos perigos.

Mas isso é por causa do tipo de marketing que fazem, quando surge uma tecnologia ou forma de trabalho nova, a vendem como se a anterior fosse um lixo, que quem usava/gostava da anterior não entende de nada, é ultrapassado, se quiser ganhar bem ou evoluir tem de usar a nova. Daí se a pessoa engolir o discurso, solta as pérolas “DBA reclama porque teme perder o emprego, já que não é mais necessário”, “não quero concatenar strings, sou um analista, não um concatenador”, “não sou dinossauro, trabalho 100% OO”.

Não precisa nem ser muito antigo na área pra perceber que as tendências na informática são cíclicas, muita coisa que é defendida hoje pode ser considerada errada amanhã e outras que eram criticadas semana que vem podem se tornar o novo padrão. Por isso que acredito que não podemos levar escolha de tecnologia como religião.

Rapaz, falou tudo. Eu já ouvi isso dezenas de vezes.
Não fosse o DBA competentíssimo que temos aqui, esse projeto já tinha ido pras cucuias!

Eu, particularmente, acho que ORM é igual remédio: faz bem, mas se tomar demais, faz mais mal que a doença.
Tenho relatórios aqui que foram feitos inicialmente com Hibernate, e levavam uns 3 minutos pra rodar; com SQL puro não chega a 10 segundos. A diferença é gritante.

Porém, se não fosse a ORM, esse projeto provavelmente não estaria no pé que está.

Fora as gambiarras que acabam ocorrendo: o cara cria uma view, mapeia essa view numa classe, e acaba programando com classes representando o banco de dados, e não o domínio do problema / solução. Fica uma bagunça sem tamanho. E pra arrumar, já viu, né? “Cadê aquele DBA de b…?”

Abraço!

Pois é. O que eu quis dizer é exatamente isso: as coisas novas são vendidas e as velhas são taxadas de ruins. E quem cai nisso, vai na fé de que o sistema vai aumentar e só mapear a nível de objeto vai resolver todos os problemas. Quando a app tá lenta por causa de gargalo de banco, o programador acha que pode ser outra coisa.

Aliás, li um comentário interessante, não em relação a ORM (mas acho que encaixa bem no assunto), mas em relação a SQL x NoSQL (que é uma das novas buzzwords).

Fonte. O trecho que coloquei é o comentário do Adam D’Angelo, fundador do Quora.

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?

Na minha opinião, pode ser usado, desde que o banco não seja criado a partir do ORM (pelo mapeamento entre objetos). O ORM serve pra mapear o banco (que já existe) em objetos, e não o contrário.

Mas isso é só uma questão de opinião / experiência. Ainda não participei de nenhum projeto em que o problema fosse o ORM.

Meus 2 cents:
Começar um projeto Java hoje sem Hibernate é inaceitável (salvo casos raros muito específicos). Precisa de algo que com o hibernate não tem uma boa performance? Ok, nada impede ter uma ou outra parte feita com SQL/JDBC puro, mas é preciso ver o real ganho nisso.
Vale a pena ter um ganho de 2 minutos (de 5 para 3) em algo que é executado uma vez por ano por exemplo? (não estou dizendo que é o caso de ninguém citado aqui)
10% de performance em algo que quase nunca é executado compensa a maior dificuldade e cuidado na manutenção de códigos SQL grandes no projeto?
É preciso analisar onde estão os gargalos (com ferramentas de profiling) e verificar quais desses são realmente gargalos que prejudicam a performance do projeto como um todo e quais são perfumaria.

Nem céu, nem inferno, ORM não resolve tudo mas é muito pior não usá-lo, basta fazer corretamente.

[]

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?

• ORM é indicado para quem tem dificuldade com SQL;

• IDE é para quem tem dificuldade com programação;

• OO é para quem tem dificuldade com matemática;

e assim por diante…

Poxa, não to sacando esse post, vou ler o link depois para entender.

Mas sem ler o link, qual é o problema com ORM?

Concordo com o Luiz.

Também não vejo o ORM um substituto do banco de dados, nem do DBA. Foi uma surpresa ler isso aqui.

O que aprendi é:

• Modela banco no tipo de banco;
• Aplicação acessa banco, “cada qual com seu cada qual”.

Em diversos projetos que trabalhei, nenhum empresa falava assim: “não temos DBA, não fazemos melhoria de performance em banco. Fale com o desenvolvedor”. Onde o banco não é levado em conta e o foco fica só na aplicação? Isto não parece ser aplicável em sistemas de verdade.

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).

Então o pessoal recomenda recriar tudo isso a cada projeto novo? Gostaria de entender o que há de tão mal no ORM.

malconL:

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?

• ORM é indicado para quem tem dificuldade com SQL;

• IDE é para quem tem dificuldade com programação;

• OO é para quem tem dificuldade com matemática;

e assim por diante…

Na boa, a discussão estava indo bem. Mas agora você falou bobagem camarada. Quer dizer então que quem sabe mesmo desenvolver modela tudo com base em teoremas, prova tudo e depois codifica no notepad ? E o resto do mundo simplesmente “tem dificuldade” ? Fala sério …

IMHO, o artigo é bem ponderado, ORM não é a melhor solução que se PODERIA ter para persistir objetos. O próprio livro do Gavin King tem uma discussão sobre o gap entre um modelo OO e um modelo relacional e os problemas que são introduzidos quando é feito esse mapeamento. Porém, sistemas OO precisam de persistência, e até então, os bancos de objetos ficam bastante atrás dos bancos relacionais, ainda. Sendo assim, não vejo o porque de não aproveitar o melhor dos dois mundos. Ao fazer tudo na mão com JDBC o mapeamento OO acaba surgindo. Depois de fazer DAO’s para 2 ou 3 classes a primeira coisa que vem à mente é usar o nome da classe para encontrar o nome da tabela e obter os getters/setters via reflection para encontrar os campos e assim montar o SQL. Isso resolve 90% dos casos, e não é nenhum impedimento para montar SQL na mão quando for preciso utilizar álgebra relacional.

Existem frameworks ORM que basicamente traduzem o resultado de uma query que você cria para um objeto. Além disso, todo framework ORM que se preze permite consultas nativas e em lote, além de retornos “não OO” como array. Então eu continuo me perguntando porque ORM seria um anti-pattern. Acho que o autor do artigo usou esse termo apenas para criar polêmica…

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é?

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).

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:

Ironlynx:

Nas empresas onde vocês trabalham vocês podem ir criando Views,Sequences, Triggers a torto e a direito?

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

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?

Aliás, prefira ter um DBA por perto mesmo utilizando ORM. É ele que vai resolver teus problemas se você errar ao modelar a base.