BT

O mapeamento objeto-relacional é um antipadrão?

por Eder Ignatowicz em 25 Out 2011 |

Em um post polêmico em seu blog, Laurie Voss, afirma que o mapeamento objeto-relacional (ORM, na sigla em inglês) está se tornando um anti-padrão (anti-pattern), apesar de se tratar de uma técnica amplamente utilizada pela comunidade de desenvolvimento. O post gerou grande repercussão, com mais de 40 comentários, e continua sendo discutido em outros blogs.

Lembrando que os antipadrões são definidos, por Scott Ambler, como "abordagens comuns, mas ineficazes, para a resolução de problemas recorrentes" e que têm duas características:

  • Inicialmente a solução aparenta ser benéfica, mas no longo prazo traz mais consequências negativas do que positivas;
  • Existe uma solução alternativa e replicável.

Laurie Voss argumenta ter sido a primeira característica a que levou a uma adoção em massa das soluções de ORM. Ou seja, o uso de técnicas de mapeamento objeto/relacional parecia inicialmente uma boa ideia, porém no momento em que os problemas se tornavam aparentes, já era tarde demais para voltar atrás.

Voss resume algumas vantagens das técnicas e ferramentas de ORM como simplicidade, geração de código e eficiência mínima, mas dá enfoque maior aos problemas, apontando os três principais:

  • Abstração inadequada. O problema mais óbvio de tecnologias ORM, segundo o autor, vem de uma abstração inadequada. Por exemplo, a documentação de grande parte das bibliotecas de ORM cita conceitos de SQL. Mas uma abstração que exige o aprendizado de SQL e de conceitos de bancos relacionais, além de uma nova API, não estaria atingindo o seu principal objetivo: simplificar e esconder do desenvolvedor os detalhes de implementação.

Defensores do ORM dirão que isso não se aplica a todos os projetos: nem todos necessitam executar joins complexos; e que o ORM é uma solução 80/20, em que 80% dos usuários necessitam de apenas 20% das funcionalidades do SQL. Mas posso dizer que nos meus quinze anos de experiência no desenvolvimento de aplicações web persistidas em banco de dados, isso não tem sido verdade. Somente no início de um projeto se pode trabalhar sem a utilização de joins ou usando-os de maneira simplista. Depois, será preciso otimizar e consolidar consultas. Mesmo considerando que 80% dos usuários utilizem somente 20% das funcionalidades do SQL, 100% terão que violar a sua abstração para fazer o que precisa ser feito.

  • Abstração incorreta: Outro problema destacado é o o uso do tipo errado de datastore. O carga adicional de recursos para usar um banco de dados relacional geralmente é grande e este é o motivo, argumenta Voss, pelo qual a tecnologia NoSQL possui desempenho superior.

O overhead de uma base de dados relacional é enorme, esta é uma das principais razões do desempenho superior de base de dados NoSQL. Contudo, se seus dados são relacionais este overhead é justificado pois seu banco de dados não somente armazena os seus dados mas também os representa. Esta representação permite que seu banco pode responder questões (queries) referente aos dados baseado nas relações capturadas.

  • Excesso de consultas. Outro problema comum do ORM, opina Voss, é a ineficiência. Na consulta de um objeto, o ORM não "sabe" quais propriedades (ou colunas de uma tabela) são necessárias e por isso traz todas elas. Ele cita que vários mecanismos de ORM têm problemas graves no gerenciamento de joins e gerando um número imenso de consultas desnecessárias. Embora sejam problemas conhecido e já se tenha tentando resolvê-los através de várias técnicas como caching e lazy-loading, o autor deixa claro que considera as soluções encontradas pouco satisfatórias.

Alternativas

Procurando demonstrar a existência de uma solução alternativa e replicável, Laurie Voss aponta duas opções:

  • Utilize objetos. Voss lembra que caso seus dados sejam objetos, você deve parar de utilizar um banco de dados relacional:

Não existe uma lei que diz que o primeiro passo no desenvolvimento web é a instalação do MySQL. O uso maciço de bases de dados relacionais para todas as representações de dados é uma das razões da recente má reputação do SQL. O problema no caso é o mal design da aplicação e não a tecnologia utilizada.

  • Utilize SQL no Model. O autor afirma que a melhor maneira de representar dados relacionais em código orientado a objetos é através de uma camada de model, ou seja encapsulá-los em uma única área de código.

É extremamente perigoso afirmar que existe "uma única maneira correta" de se resolver qualquer problema em programação. Mas baseado na minha experiência, a melhor maneira de se representar dados relacionais em código orientado a objeto é através de uma camada de Model que encapsule a representação dos dados em uma única área de código. Contudo lembre-se que o trabalho da sua camada de Model não é representar objetos mas sim responder questões.

Concluindo, Laurie Voss afirma que devemos resistir à falácia de que a orientação a objetos pode representar qualquer coisa. A OO, diz, é uma abstração elegante e flexível, mas abstrair dados relacionais é um dos seus pontos fracos. Acreditar que objetos podem modelar dados relacionais é, segundo o autor, a raiz de todos os problemas com ORM.

Voss fecha o artigo com um resumo dos principais pontos levantados, entre os quais destacamos:

  • As vantagens da utilização de ORM desaparecem com o aumento da complexidade pois é necessário promover uma quebra da abstração forçando o desenvolvedor a lidar com SQL;
  • Objetos não são uma forma adequada de representação de queries relacionais;
  • Ao invés de se utilizar bases de dados relacionais e ORM como solução de todos os problemas, se seus dados são objetos por natureza utilize NoSQL;
  • Design OO não pode representar dados relacionais de forma eficiente, isto é uma limitação fundamental do design OO que ORM não pode lidar.

E você leitor qual é a sua opinião sobre tecnologias de ORM? E qual a sua experiência na adoção deste tipo de tecnologias?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

OO não é ORM by Fabio Santos

Outra questão importante a ser ressaltada é que OO não é ORM, ou seja, é possível ter OO sem ORM. A minha experiência mostra que OO pode ser usado para modelar a maior parte dos problemas de forma simples e elegante, mas o mapeamento relacional diminui significativamente esta elegância e simplicidade.

Para mim, o ORM reduz o escopo e interfere na modelagem orientada a objetos. Isso ocorre, por exemplo, na medida em que automatiza a construção dos objetos de domínio, dificultando o uso de ferramentas como construtores e inversão de controle.

A questão do desempenho de consultas, no entanto, me parece ser periférica. Prefiro sempre otimizar depois, e as ferramentas ORM, em geral, permitem alguma flexibilidade de otimização.

ORM não é mágica by Edson Alves

Esta relação da definição de Scott Ambler sobre anti padrão, "abordagens comuns, mas ineficazes, para a resolução de problemas recorrentes", que é à base da discursão do artigo, onde o autor afirmar que o uso ORM proporciona Abstração inadequada, Abstração incorreta e Excesso de consultas para os projetos, no mínimo falta mais embasamento.

Na minha experiência, o problema na utilização de soluções ORM é a facilidade de aprendizagem e configuração não obrigatória. Apesar de possuir vasta documentação, algumas horas de leitura são o suficiente para se produzir algo funcional, essa realidade tornar o desenvolvedor quase sempre um analfabeto funcional na ferramenta. Essa questão lembra o conceito de "bad smells", proposto por Martin Fowler, que diz que "na pressa para entregamos o que funcionar para o cliente, nem sempre possuímos tempo para analisar que nos parece errado".

Portanto, ORM é um anti padrão quando não utilizado de forma correta e uma ferramenta de qualidade quando se estuda como empregar.

Excesso de consultas by Tiago Dolphine

ORM com certeza traz vantagens e desvantagens conforme citado no post, tivemos grandes problemas em um projeto com o Excesso de consultas que deixava o sistema extremamente lento devido a acesso a banco desnecessário, grande parte dele por falta de análise de performance, n+1 selects, e principalmente por mapeamento mal feito, o que foi resolvido com normalização das entidades, caching adequado, testes, geração de estatísticas. Minha opinião é ORM não é perfeito mas grande parte dos problemas é causada pelo uso inadequado e muitas vezes sem análises mais elaboradas do mapeamento de entidades e principalmente desconhecimento do funcionamento do framework ORM utilizado.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

3 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT