Olá Galera!
Gostaria de saber a opinião de vocês sobre o seguinte post onde o autor afirma que apesar das vantagens, a longo prazo o ORM é considerado 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. 
[quote=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.
[/quote]
Faça o teste e nos conte depois, seria interessante mostrar essa diferença…
[]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. [/quote]
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.
[]
[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]
-
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.
[quote=malconL][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]
-
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…
[/quote]
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…