Bueno, una cosa que es importante hacer cuando tenemos una discusión como esta es distinguir claramente entre mapeadores relacionales de objetos ("ORM") y las capas de abstracción de la base de datos . Un ORM es un tipo de capa de abstracción de base de datos, pero no todas las capas de abstracción de base de datos son ORM. Una buena herramienta para estudiar para comprender esto es la popular biblioteca SQLAlchemy de Python , que se autodenomina como un "kit de herramientas SQL y Object Relational Mapper" (mi negrita), con la idea de que estas son cosas diferentes. Como lo pusieron en su página de características clave :
No se requiere ORM
SQLAlchemy consta de dos componentes distintos, conocidos como Core y ORM . El Core es en sí mismo un conjunto de herramientas de abstracción SQL con todas las funciones, que proporciona una capa uniforme de abstracción sobre una amplia variedad de implementaciones y comportamientos de DBAPI, así como un lenguaje de expresión SQL que permite la expresión del lenguaje SQL a través de expresiones generativas de Python. Un sistema de representación de esquemas que puede emitir sentencias DDL, así como introspectar esquemas existentes, y un sistema de tipos que permite cualquier mapeo de tipos de Python a tipos de bases de datos, completa el sistema. El Object Relational Mapper es un paquete opcional que se basa en el Core.
La primera página describe el ORM de esta manera:
SQLAlchemy es famoso por su mapeador relacional de objetos (ORM), un componente opcional que proporciona el patrón del mapeador de datos, donde las clases se pueden mapear a la base de datos de forma abierta, de múltiples formas, permitiendo que el modelo de objetos y el esquema de la base de datos se desarrollen de una manera limpiamente desacoplado desde el principio.
La idea clave de un ORM es tratar de salvar el famoso desajuste de impedancia relacional de objetos . Esto significa definir las relaciones entre las clases definidas por el usuario con las tablas en un esquema de base de datos y proporcionar operaciones automáticas de "guardar" y "cargar" para las clases de su aplicación.
En contraste, las capas de abstracción de bases de datos que no son ORM tienden a estar más comprometidas con el modelo de datos relacionales y con SQL, y no con la orientación a objetos. Entonces, en lugar de presentar "asignaciones" entre tablas y clases y ocultar el esquema de la base de datos del programador, tienden a exponer la base de datos al programador pero con mejores API y abstracciones. Por ejemplo, los constructores de consultas SQL le permiten generar consultas SQL complejas mediante programación, sin manipulación de cadenas, como este ( un ejemplo de la 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();
Ahora, el marco de Play no parece estar 100% en línea con lo que acabo de describir , pero su argumento parece estar en este espacio general: trabaje con el modelo relacional directamente en lugar de traducirlo a clases y viceversa.
La biblioteca jOOQ es digno de estudio como contrapunto a ORM. También tienen algunas entradas de blog relevantes que vale la pena leer: