Taverna /dev/All

ORM: herói ou vilão?

Topei com um texto muito bom do Otávio Santana (https://www.infoq.com/br/articles/orms-herois-ou-viloes/) no InfoQ com o título “ORMs: heróis ou vilões dentro da arquitetura de dados?” que nos dá motivo para uma boa discussão aqui na Taverna.

ORMs fazem parte da minha vida desde 2003, 2004 quando tive meu primeiro contato com o Hibernate. Mudou minha vida pra dizer o mínimo e desde então são algo que considero quase indiscutível. Note: quase indiscutível.

Quase indiscutível por que recentemente topei com alguns projetos nos quais o ORM não foi usado e pra minha surpresa não foi algo tão ruim assim. Na realidade foi bastante positivo: o ganho foi enorme. Sendo assim gostaria de ouvir a opinião de vocês a respeito já que nem se discute mais esta questão. Qual a opinião de vocês sobre este assunto?

PS: o Database Cast teve um episódio muito tempo atrás sobre ORM que, apesar de achar muito fraquinho (basicamente só fala o óbvio) talvez agregue algo nesta discussão também. https://imasters.com.br/back-end/databasecast-orm

1 Curtida

Eu acho que é mais vilão do que herói. Isso porque ele adiciona uma camada de complexidade quando se leva em conta configurações. Você vai ter um ganho lá na frente quando poder usar os mapeamentos. Isso me faz questionar se realmente vale a pena ter tanta dor de cabeça com essas configurações de orms. Talvez usar o SQL, de forma sensata, seja muito mais produtivo.

mas de qual ORM você tá falando aqui?

O JPA/Hibernate, por exemplo, hoje tem como configurações muito pouca coisa: essencialmente as anotações (sendo que podem inclusive ter algumas opcionais) e a conexão de acesso ao banco de dados, que teríamos de qualquer modo no acesso normal no Java via data sources.

O mesmo observo também (com muito menos experiência, é claro) no Entity Framework do .net: a maior parte das configurações dizem respeito à conexão com o banco de dados.

Me refiro ao hibernate mesmo. Hoje melhorou bastante, e tem coisas que podem ser configuradas com anotações. Algumas coisas como relacionamentos são mais simples na minha opinião usando SQL. Muitos problemas são gerados configurando relacionamentos nas entidades diretamente nas classes. Eu vivo corrigindo isso no trabalho. Se a consulta e o update for muito complexo até entendo. Fora isso, um SQL simples é bem mais eficaz na minha opinião.

Estes relacionamentos podem ser dramáticos mesmo: podem dar muita dor de cabeça e um problema monstruoso de desempenho.

Criei até uma estratégia pra lidar com isto do ponto de vista arquitetural, chamo ela de “estratégia do pai inconsequente”: https://www.itexto.com.br/devkico/?p=1097 (post velho, 7 anos atrás!)

1 Curtida

Pra mim tudo que não é 100% baseado em escrever SQL é pior. Ter sempre o controle do SQL é mais eficaz, sem falar do excesso de overhead desses ORMs completos.

1 Curtida

Os orms tem um sistema de cache que ajudam na performance. O problema, para mim no caso só diz respeito a leitura de código e alguns problemas de complexidade de relacionamentos. Então eu não creio que todos os sistemas deveriam usar essa solução. Somente os gigantes com determinados klocs.

Eu amei ORMs (uso Django, framework do Python) quando, em uma situação de emergência, enquanto meus colegas estavam conectados ao servidor MySQL com um cliente nativo, escrevendo queries longas e complexas, eu entrei no shell do django, que me dá acesso ao ORM e a todo o código do sistema, e consultei de forma muito simples o que era necessário. E ainda pude manipular os resultados com as facilidade do Python.

Eu odiei ORMs quando me foi atribuída uma tarefa que implicava em caçar por todo o código (um código horrível) onde as consultas eram feitas para implementar uma filtragem global por conta de uma nova regra de negócios. O ORM do django provê uma coisa chamada Manager, pra esses causos. Mas quem é que usa?

Mas,seja SQL ou seja ORM as barbaridades tem grandes chances de ocorrerem.

Os ORMs facilitam demais a maioria dos problemas que enfrentamos cotidianamente.

Eu estou tendendo, inspirado no manager, a priorizar queries diretas, centralizadas, mas isso faz com que seja necessário escrerver muita coisas que um ORM já faz e muito bem…

A luz que vejo é algo que supere a linguagem de consulta SQL, mantendo sistemas de banco de dados relacionais, mas incorporando novidades do mundo NoSQL, como o edgedb:

https://edgedb.com/

1 Curtida

itexto