Newsgroup: it.comp.lang.c++
Titolo: C++ e ORM

Sto provando a realizzare una libreria che mi faccia da bridge ORM tra Classi e DB. Mi sto affidando alle librerie Qt per l'infrastruttura sottostante, quindi QObject a più non posso...
Qualcuno potrebbe suggerire un'idea o un punto di vista? Purtroppo sono il classico lupo solitario per forza di cose, e ho così tanta confusione in testa che vorrei uno scossone con una visione esterna per fare un po' di ordine...!
Grazie in anticipo.

Vedo che non mi ha calcolato nessuno... Ho sbagliato qualcosa? Ho infranto qualche netiquette?
Se ho fatto qualcosa ditemelo! Sono relativamente nuovo, e non vorrei cominciare con il piede sbagliato!


Non vedo niente di sbagliato nel post, il gruppo è
costituito da persone disponibili. Credo che molto
semplicemente chi ha letto non sa la risposta oppure il
tuo post non è ancora stato visto da chi potrebbe
risponderti - che potrebbe benissimo non capitare mai su
questo NG.
 
-- 
"La teoria è sapere come funzionano le cose e
non sapere come farle funzionare; la pratica è
sapere come far funzionare la cose senza sapere come
funzionano; il nostro scopo è unire la pratica
alla teoria per riuscire a non far funzionare
le cose senza capire come abbiamo fatto"
 

 Se ho fatto qualcosa ditemelo! Sono relativamente nuovo, e non vorrei cominciare con il piede sbagliato!
 
Io il post l'avevo letto ma di Qt non ci capisco abbastanza per poter dare una riposta.
Solitamente sui NG non ci sono post del tipo "non lo so", e si risponde solo quando si ha un suggerimento più o meno valido.
Fondalmente poi la tua più che una domanda specifica era un disegno di architettura che, detto così, non avrebbe nulla che non va (a parte che, ad esempio, a me non piace il concetto di ORM, ma questa è un'altra storia)
Ciao!


... e dimmi come mai il concetto di ORM non ti piace? Vorrei saperlo! Di qualcosa puoi farti un'idea corretta solo dopo che ci hai avuto a che fare e sentito i pareri pro- e contro-!

 ... e dimmi come mai il concetto di ORM non ti piace? Vorrei saperlo! Di qualcosa puoi farti un'idea corretta solo dopo che ci hai avuto a che fare e sentito i pareri pro- e contro-!
 
Mah, fondamentalmente perché ritengo sia un errore "logico" nell'architettura del software.
 
Si mette un layer per la gestione dei dati (storage), un altro layer per la gestione dei dati (ORM) che fa la stessa cosa del layer sotto, e poi un layer per l'astrazione dei dati (classi applicative). E metà delle volte bisogna aggirare il secondo layer perché non ci permette di fare quello che vogliamo.
 
E tutto questo perché?
Perché lo SQL è "sporco" / non lo sappiamo usare? Suvvia.
Perché ci fa il caching? Il caching degli oggetti è una pezza per aggirare il fatto che è un sistema bacato alla base a causa dell'inapplicabilità pratica delle idee di alto livello ai meccanismi di storage(*), che nel migliore dei casi mi riempie immense quantità di memoria inutilmente.
Perché così "superiamo la differenza di paradigma tabelle/oggetti"? Abbiamo già un layer software per quello, non ce ne serve un altro.
Perché scriamo meno codice? ahaha, sì, come no. Eppure ho visto persone pensare che si facesse prima/fosse più pulito riconfigurare/ricompilare un'applicazione che utilizzava hibernate piuttosto che cambiare una stringa di query.
 
(*) il fatto che in SQL ci siano insert/update/create/delete *non* significa che posso seguire un approccio CRUD.
 
IMHO queste cose si chiamano "mode", e sono seguite solo da chi o 1- non ha abbastanza esperienza (o, nel caso di un'azienda, coraggio di dire a chi di dovere che ha scelto una tecnologia stupida) o 2- ha la mente così tanto piena di preconcetti e slogan (di chi queste "tecnologie" le spinge) da non vedere la differenza effettiva tra l'approccio nuovo e l'approccio "classico".
 
Sorry per il rant, ma descrivere qualcosa che mi fa schifo in maniera più.. educata.. va oltre le mie capacità :-)
 
Ciao!


Non preoccuparti per il rant, ci sta bene se motivato! Comunque, ho capito che intendi dire, perché crearmi un'astrazione delle tabelle se un SQL server/driver lo fa già per me! Ci stà come discorso.
In questo ti do' pienamente ragione. E' come "aggiustare" una cosa che funziona!
 
Ora, credo però di aver generalizzato il tutto con ORM. In effetti sto' provando a fare un "ORM" perché quello che c'è in giro non mi piace! Forse perché quello di cui ho il desiderio non si chiama ORM!
In effetti io non desidero fare il mapping tra i field di una tabella che appartiene ad un DB realizzato nel modo "Classico" e i field di un oggetto.
Questo perchè il modello relazionale "pensa" alla sua struttura in un modo differente dal modello OO.
 
Quello che vorrei fare è una "traduzione" di una rappresentazione COERENTE OO del mio parco Oggetti in una rappresentazione COERENTE RELAZIONALE per il modello OO in un DB per rendere gli Oggetti permanenti, come congelarli, per poi scongelarli alla necessità, il tutto realizzato dagli oggetti verso le relazioni, e non dalle relazioni e oggetti al mapping.
Sostanzialmente vorrei creare un layer OO per rendere un DBRelazionale in un DBOO e non un layer Oggetto mappato su un DB Relazionale.
Una sorta di "compilazione" della miei Oggetti in una struttura relazionale, e non ho per niente intenzione di avere anche la facoltà di esplorare le tabelle e le relazioni e capirci qualcosa in maniera facile! Questo perchè il layer dovrà tenere traccia dell'eventuale ereditarietà, composizione, polimorfismo, ecc.. degli oggetti e quindi l'interno del DB sarà molto caotico(metematicamente parlando).
 
Spero di essermi spiegato... e sono io a rileggermi... e mi capisco a stento.

 Spero di essermi spiegato... e sono io a rileggermi... e mi capisco a stento.
 
Sì, penso di aver capito :)
In ogni caso come approccio te lo sconsiglio vivamente, visto che in questo modo elimini il disaccoppiamento tra dati e codice, in pratica lengando i dati ad una implementazione specifica (il che è ovviamente male).
Ti direi di dare un'occhiata ai DB non relazionali (NoSQL), di cui però ho solo sentito parlare mooolto da lontano (e magari non fanno al caso tuo).
Ciao!

 Ciao!
 
Ci darò immediatamente un'occhiata, grazie!

 
 
Non so in pratica come lo stai realizzando ma, così come l'hai descritto, al cambiare del disegno delle classi (o di un semplice refactoring) dovresti cambiare la struttura dell base di dati.. no?
Ciao!

 refactoring) dovresti cambiare la struttura dell base di dati.. no?
 
Certo, ma questo succede anche senza ORM!
 
 
Ciao  Manlio


No, perché? Semmai non succede né con né senza ORM (in entrambi i casi siamo isolati da un layer apposito). Quello che specificava l'OP invece era una specie di "serializzazione" delle classi nel DB, che è un'altra storia.
Ciao!

 [...]
 
 
Ciao  Manlio


Puoi partire da qui:
http://en.wikipedia.org/wiki/Object-relational_mapping
 
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
 
 
 
Ciao  Manlio

 
 
Ma sì, questo è ovvio. Si disquisiva di altro.
 
Ciao!


Questo dipende dal pattern usato dall'ORM:
http://en.wikipedia.org/wiki/Active_record_pattern
 
http://en.wikipedia.org/wiki/Data_mapper_pattern
 
 
Ad esempio io uso SQLAlchemy (Python), che usa il Data Mapper pattern (ma 
non uso l'ORM); invece non userei mai (se dipendesse da me) gli ORM che 
usano l'Active Record pattern (come Django).
 
 
Ciao  Manlio


Ehehe, in pratica stai dicendo che come approccio non piace neppure a te! ;)
 
Interessante la differenza che riporti, pensavo che per ORM si intendessero solo quelli del primo tipo.
 
Ciao!

 
 
 
Ciao  Manlio