Bene, una cosa che è importante fare ogni volta che abbiamo una discussione come questa è di 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 per capire questo è la popolare libreria SQLAlchemy di Python , che si autodefinisce come "toolkit SQL e Object Relational Mapper" (il mio grassetto), con l'idea che si tratta di cose diverse. Come lo inseriscono nella pagina delle caratteristiche principali :
Nessun ORM richiesto
SQLAlchemy è costituito da due componenti distinti, noti come Core e ORM . Il Core è esso stesso un toolkit di astrazione SQL con funzionalità complete, che fornisce un livello uniforme di astrazione su un'ampia varietà di implementazioni e comportamenti DBAPI, nonché un linguaggio di espressioni SQL che consente l'espressione del linguaggio SQL tramite espressioni generative di Python. Un sistema di rappresentazione dello schema che può sia emettere istruzioni DDL che schemi esistenti introspetti e un sistema di tipi che consente qualsiasi mapping dei tipi Python ai tipi di database, completa il sistema. Object Relational Mapper è quindi un pacchetto opzionale che si basa sul Core.
La prima pagina descrive l'ORM in questo modo:
SQLAlchemy è famoso soprattutto per il suo ORM (object-relational mapper), un componente opzionale che fornisce il modello di mappatore di dati, in cui le classi possono essere mappate al database in modo aperto, in diversi modi - consentendo al modello a oggetti e allo schema del database di svilupparsi in un modo chiaramente disaccoppiato dall'inizio.
L'idea chiave di un ORM è quella di provare a colmare il famoso disadattamento dell'impedenza relazionale oggetto . Ciò significa definire relazioni tra classi definite dall'utente e 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 di database non ORM tendono a impegnarsi maggiormente nel modello di dati relazionali e in SQL e non nell'orientamento agli oggetti. Quindi, invece di presentare "mappature" tra tabelle e classi e nascondere lo schema del database al programmatore, tendono ad esporre il database al programmatore ma con API e astrazioni migliori. Ad esempio, i compilatori di query SQL consentono di generare query SQL complesse a livello di codice , senza manipolazione di stringhe, come questa ( 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 combutta con quello che ho appena descritto , ma il loro argomento sembra essere in questo spazio generale: lavorare direttamente con il modello relazionale invece di tradurlo in classi e tornare da loro.
La biblioteca jOOQ vale la pena studiare come contrappunto alla ORM. Hanno anche alcuni post di blog pertinenti che vale la pena leggere: