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?