Bene, una cosa che è importante fare ogni volta che facciamo una discussione come questa è distinguere chiaramente tra mappatori relazionali di oggetti ("ORM") e livelli di astrazione del database . Un ORM è un tipo di livello di astrazione del database, ma non tutti i livelli di astrazione del database sono ORM. Un buon strumento per studiare è la famosa libreria SQLAlchemy di Python, che si autofinanzia come "toolkit SQL e Object Relational Mapper "(my boldface), con l'idea che queste sono cose diverse. Mentre lo inseriscono nella loro pagina delle caratteristiche principali :
No ORM Required
SQLAlchemy consists of two distinct components, known as the Core and the ORM. The Core is itself a fully featured SQL abstraction toolkit, providing a smooth layer of abstraction over a wide variety of DBAPI implementations and behaviors, as well as a SQL Expression Language which allows expression of the SQL language via generative Python expressions. A schema representation system that can both emit DDL statements as well as introspect existing schemas, and a type system that allows any mapping of Python types to database types, rounds out the system. The Object Relational Mapper is then an optional package which builds upon the Core.
La prima pagina descrive l'ORM come questo:
SQLAlchemy is most famous for its object-relational mapper (ORM), an optional component that provides the data mapper pattern, where classes can be mapped to the database in open ended, multiple ways - allowing the object model and database schema to develop in a cleanly decoupled way from the beginning.
L'idea chiave di un ORM è provare a superare il famoso disadattamento dell'impedenza relazionale dell'oggetto . Ciò significa definire le relazioni tra classi definite dall'utente alle tabelle in uno schema di database e fornire operazioni di "salvataggio" e "caricamento" automatiche per le classi dell'applicazione.
Al contrario, i livelli di astrazione del database non-ORM tendono ad essere maggiormente dedicati al modello di dati relazionali e a SQL, e non all'orientamento agli oggetti. Quindi, invece di includere "mappature" tra tabelle e classi e nascondere lo schema del database dal programmatore, tendono a esporre il database al programmatore ma con migliori API e astrazioni. Ad esempio, i creatori di query SQL consentono di generare query SQL complesse a livello di codice, senza manipolazione delle stringhe, come questo ( un esempio dalla libreria jOOQ per 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();
Ora, il framework Play non sembra essere al 100% in lega con quello che ho appena descritto , ma la loro argomentazione sembra essere in questo spazio generale: lavorare direttamente con il modello relazionale invece di tradurlo in classi e ritornare da esse.
Vale la pena studiare la libreria jOOQ come contrappunto agli ORM. Hanno anche alcune voci di blog rilevanti che vale la pena leggere: