Newsgroup: it.comp.lang.delphi
Titolo: Oggetti & Transazioni

DOMANDA DELLE CENTO PISTOLE :
Stò costruendo un framework per un programma di schedulazione della
produzione. Il Framework è completamente ad oggetti.  Gli oggetti vengono
mappati su storage via SQL.
La domanda è questa .. :
E' meglio gestire le transazioni all'interno degli oggetti oppure gestirle
esternamente ?
Ovvero: Dovrebbe esser compito degli oggetti committare i propri dati oppure
è meglio committarli all'esterno degli oggetti ?
Considerate che nel primo caso si avrebbe come conseguenza la minor
riutilizzabilità del codice, nel secondo caso un minore 'Information
Hiding'..
-=SIMO=-

esternamente ?
Io metteri una proprieta bool negli oggetti che indica se il commit è
automatico o manuale.
In questo modo salvi capra&cavoli, anzi, riutilizzabilita&infoHiding.
Saluti
AS
"Se è Microsoft non funziona"

 Tra parentesi, lo inizi ora, ad agosto?
Assolutamente no !
E' da un pò che mi gira in testa quel problema e non ho trovato una
soluzione soddisfacente così prima di partire x le ferie ho pensato di
postarlo.
Ciao,
-=SIMO=-

 Visto che lo stai scrivendo, mi spieghi che cacchio è un framework?
Dai un'occhiata in:
 
http://www.cetus-links.de/oo_frameworks.html
-- 
Roberto Lupi

esternamente ?
Dovresti delegare la gestione delle transazioni ad un apposito
oggetto. Se stai usando un pattern language troverai sicuramente un
oggetto Transaction che si occupa di questo (io vi incapsulerei un
TDatabase all'interno).
Hai qualche buon riferimento per Delphi sull'argomento? Finora non
trovo altro che applicazioni per Java e Smalltalk.
Hai visto Bold (
www.boldsoft.com
)? Realizza da se' lo strato ad
oggetti persistenti, e puoi interrogarli attraverso l'OCL.
E' molto intressante, ma non ho ben capito quanto spazio lascia per la
personalizzazione della base dati (infatti la genera tutto da solo,
anzi, neanche hai bisogno di vedere com'e' fatta).
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bop...@tin.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

 anzi, neanche hai bisogno di vedere com'e' fatta).
Si, gli ho dato un'occhiata, ma non voglio legarmi a prodotti commerciali.
Eppoi vorrei il controllo del layer di persistenza perchè ho in mente di mig
rarlo a Kylix, non appena pronto..
Ciao,
-=SIMO=-

	
http://www.cetus-links.de/oo_frameworks.html
Ma anche (e soprattutto) :
http://www.cetus-links.org/oo_db_systems_3.html
:-)


ne pensi ?
La tecnica + elegante, secondo me, e' di usare una variabile privata
isChanged (o isDirty) e un metodo pubblico save in ogni oggetto.
Scriveresti quindi delle procedure del tipo:
Transaction.begin;
anObject.save; //se la sbriga lui se deve scrivere sul DB o meno
anotherObject.save; //idem
Transaction.commit;
Oltretutto l'oggetto potrebbe, all'atto della distruzione, verificare
se e' stato salvato o meno, e in tal caso sollevare un'eccezione (un
po' come fa Bold). 
Cosi' pero' dovrai implementare un meccanismo per notificare
all'oggetto che una delle sue proprieta' e' cambiata (basta un
isChanged:=true nel metodo Set#### di ogni proprieta').
Ti consiglio, prima di cimentarti nell'impresa, di visitare il sito di
Scott Ambler (
www.ambysoft.com
), e di leggere i suoi articoli sul
mapping OO->RDB, contengono consigli veramente preziosi.
Infine, puoi dirmi, finora, quanto sei riuscito a riusare delle classi
fornite dalla VCL? Io mi trovo nel dubbio di riadattarne o meno
alcune: TField sarebbe ideale come variabile privata per gli attributi
delle classi concrete, TUpdateSQL potrebbe mantenere le operazioni
CRUD, ecc.
Francamente non mi va di riscrivere qualcosa che gia' esiste (magari
migliore di come lo farei io), ma non sono sicuro di quanto e'
possibile adattare della VCL. Che approccio stai usando?


 mapping OO->RDB, contengono consigli veramente preziosi.
Ho letto "Mapping Objects to Relational Databases" e l'ho trovato veramente
utile.
Grazie x l'info.
Ciao,
-=SIMO=-

Quali vantaggi porterebbe ?
E' che avrebbe gia' tutti i metodi per le conversioni di tipo, la
verifica di valore NULL, gli eventi di notifica dei cambiamenti...
Pero' mi sembra che la guida sconsigli di usarli slegati da un qualche
TDataset.
Credo che rinuncero', vorrei ottenere un framework abbastanza astratto
e riusabile magari anche su altri ambienti (Kdevelop, Jbuilder...)


 "Connecting Business Objects to Relational Databases".
L'ho scaricato e credo, da una prima impressione, che sarà utilissimo,
sopratutto perchè è abbastanza 'leggero'..
Un'ultima domanda:
Come hai risolto il problema del caricamento parziale o totale delle
proprietà dell'oggetto ?
Ho sentito pareri discordanti sull'argomento..
Ciao,
-=SIMO=-