Bem, uma coisa que é importante fazer sempre que tivermos uma discussão como essa é distinguir claramente entre mapeadores relacionais de objetos ("ORM") e camadas de abstração de banco de dados . Um ORM é um tipo de camada de abstração de banco de dados, mas nem todas as camadas de abstração de banco de dados são ORMs. Uma boa ferramenta para estudar para entender isso é a popular biblioteca SQLAlchemy do Python , que se apresenta como um "kit de ferramentas SQL e o Mapeador Relacional de Objetos" (meu negrito), com a idéia de que essas são coisas diferentes. Como eles colocam na página de recursos principais :
Não é necessário ORM
O SQLAlchemy consiste em dois componentes distintos, conhecidos como Core e ORM . O Core é ele próprio um kit de ferramentas de abstração SQL completo, fornecendo uma camada suave de abstração sobre uma ampla variedade de implementações e comportamentos DBAPI, além de uma linguagem de expressão SQL que permite a expressão da linguagem SQL por meio de expressões generativas em Python. Um sistema de representação de esquema que pode emitir instruções DDL, bem como examinar os esquemas existentes, e um sistema de tipos que permite qualquer mapeamento de tipos Python para tipos de banco de dados, complementam o sistema. O Object Relational Mapper é então um pacote opcional que se baseia no Core.
A primeira página descreve o ORM assim:
O SQLAlchemy é mais famoso por seu ORM (Object-Relational Mapper), um componente opcional que fornece o padrão do mapeador de dados, no qual as classes podem ser mapeadas para o banco de dados de várias maneiras abertas - permitindo que o modelo de objeto e o esquema do banco de dados se desenvolvam bem dissociada desde o início.
A idéia principal de um ORM é tentar colmatar a famosa incompatibilidade de impedância objeto-relacional . Isso significa definir relacionamentos entre classes definidas pelo usuário para tabelas em um esquema de banco de dados e fornecer operações automáticas de "salvar" e "carregar" para as classes do seu aplicativo.
Por outro lado, as camadas de abstração de banco de dados que não são do ORM tendem a ser mais comprometidas com o modelo de dados relacional e com o SQL, e nada com a orientação a objetos. Portanto, em vez de apresentar "mapeamentos" entre tabelas e classes e ocultar o esquema do banco de dados do programador, eles tendem a expor o banco de dados ao programador, mas com melhores APIs e abstrações. Por exemplo, os construtores de consultas SQL permitem gerar consultas SQL complexas programaticamente, sem manipulação de cadeias, como este ( um exemplo da biblioteca jOOQ para Java ):
// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
.from(BOOK)
.join(AUTHOR)
.on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.PUBLISHED_IN.equal(1948))
.fetch();
Agora, o framework Play não parece 100% compatível com o que acabei de descrever , mas o argumento deles parece estar neste espaço geral: trabalhe diretamente com o modelo relacional em vez de traduzi-lo para as classes e voltar a partir dele.
A biblioteca jOOQ vale a pena estudar como um contraponto à ORMs. Eles também têm algumas entradas de blog relevantes que valem uma leitura: