Newsgroup: it.comp.lang.delphi
Titolo: componenti db-aware

Io sono rimasto a Delphi 6 (e non uso delphi da  abbastanza).
Non ho mai amato i componenti come dbgrid ecc perche' lavorano direttamente 
con le tabelle relazionali.
Quindi spesso ho preferito lavorare con componenti che non si connettono al 
database, che tuttavia bisogna riconoscere essere un po' scomodi rispetto 
agli altri.
Sarebbe interessante se avessero sviluppato componenti "model aware" (me lo 
sono appena inventato), cioè che predono come sorgente gli oggetti (il 
model) della mia applicazione anzichè le tabelle direttamente (ad esempio 
una griglia "sincronizzata" sugli oggetti restituiti da un metodo del form 
GetOrders).
Nelle altre versioni di delphi ci sono stati passi in questa direzione o 
continuano a produrre nuovi componenti sempre + pieni di feature ma ancora 
agganciati alle tabelle relazionali?
Se cose' perche' la comunita' delphi non si muove in quell'altra direzione?

Se cose' perche' la comunita' delphi non si muove in quell'altra direzione?
Perché i componenti DB-aware sono estremamente utili, sono la scelta
ideale in molti più casi di quanto si possa pensare e la scarsa voglia
di utilizzarli è troppo spesso dovuta all'incompetenza e non a reali
decisioni di design.

 decisioni di design.
Considera la volonta' di usare un mediatore tra il proprio model e i 
componeti grafici.
Mi sembra un'ottima scelta, un programma di buona dimensioni beneficia 
solitamente di un architettura di questo tipo.
Se uso i soliti componenti db aware non posso assolutamente usare il 
mediatore per "renderizzare" i miei componenti grafici. 

mediatore per "renderizzare" i miei componenti grafici. 
Come ti ho già detto sopra, questo è assolutamente falso.
I componenti db-aware "conoscono" solo l'interfaccia TDataSource,
ovvero la loro fonte dati.  Come fonte dati si può usare qualsiasi
cosa.  E' studiato apposta in questo modo.

 cosa.  E' studiato apposta in questo modo.
Mi sono guardato il ClientDataSet.
La griglia agganciata al datasource che e' agganciato al dataset potrebbe 
richiamare qualsiasi (forse non qualsiasi ma mi dovrei imparare il dbgrid a 
memoria per usarlo) evento del clientdataset.
Devo scrivere codice per una quarantina di eventi per ogni clientdataset se 
voglio usare uno strato di oggetti. 

voglio usare uno strato di oggetti. 
Non capisco proprio che cosa vuoi dire...

 Non capisco proprio che cosa vuoi dire...
Allora...appunto per convincermi vorrei provare a creare un DBGrid che si 
collega a un DataSource, il quale e' collegato a un ClientDataSet.
Facciamo che il modello e' costituito da un oggetto TUser che contiene nome 
e cognome.
L'idea da implementare  e' questa: clicco un bottone e il grid deve essere 
riempito con i dati di 5 user create da me al momento (dei quali visualizza 
nome e cognome in 2 campi separati).
Nota che non so usando nessun database, sto solo crando oggetti in memoria.
Che eventi (denotro il ClientDataSet o DataSource) dovrei gestire per fare 
questo? 

questo? 
Non devi usare alcun evento, devi far sì che la tua TUserList sia
interfacciabile esponendo un'interfaccia TDataSet.  Per farlo, puoi
costruire una classe "Controller" secondo il pattern MVC.  Ti
consiglio di documentarti a riguardo.
In ogni caso, ti consiglio ancora una volta di dare uno sguardo a come
funziona InstantObjects.  C'è anche un video di demo liberamente
scaricabile.


Ora il ClientDataSet si collega tramite un altro DataSource alla mia 
TUserList.
Ora il compilatore mi suggerisce di implementare 6 metodi della TUserList 
che sono astratti.
Il problema e' che non ho assolutamente idea di cosa dovrebbero fare questi 
metodi.
Qualcuno conosce esempi di questo disponibili sul web? 

che sono astratti.
 ???

 ha scritto nel messaggio 
news:sv4mp1ppccpjur702...@4ax.com...

TUserList = class(TDataSEt)....
TDataSet ha alcuni metodi astratti come ben saprai...
Bisogna scrivere un sacco di metodi per farlo funzionare.
Non e' certo facile comunque creare un TDataSet personale, potevano fornire 
qualche sottoclasse astratta a questi scopi. 

qualche sottoclasse astratta a questi scopi. 
Sei tu che non conosci esattamente ciò che stai utilizzando.
Ti consiglio di scaricare i sorgenti di InstantObjects.


Tu hai detto "...devi far sì che la tua TUserList sia
interfacciabile esponendo un'interfaccia TDataSet".
non sigifica questo fare TUserList = class(TDataSet)  ?

non sigifica questo fare TUserList = class(TDataSet)  ?
No.

 ha scritto nel messaggio 
news:388mp1dka669teh9r...@4ax.com...

Si. 

Si. 
NO.
Il tuo modo di insistere su argomenti che non conosci è davvero
snervante.  Se tu avessi letto e compreso ciò che ho scritto nei
messaggi precedenti, avresti anche saputo che non ti stavo suggerendo
di ereditare da TDataSet.  Chiudo la discussione raccomandandoti, come
già fatto altre volte, di scaricare i sorgenti di InstantObjects e
studiarteli.

 studiarteli.
Gia' fatto e grazie. 

La prossima volta sii piu' educato[...]
Io non sono obbligato a risponderti, ma lo sto facendo, chi deve
conservare la buona educazione, innanzitutto, sei tu.  Rileggi i tuoi
messaggi e poi vediamo se sei stato sufficientemente educato nei
confronti di una persona che ti sta dando dei suggerimenti.

 che faccia da "ponte" tra il modello e la visualizzazione del modello.
Notare che anche te hai detto necessariamente non significa questo, quindi 
se ho capito male sono piu' che giustificato.
Anche se avessi capito male e basta non vedo perche' dovrei essere 
snervante.
Notare che continui a non voler spiegare, ripetere quanto scritto sopra non 
serve. Forse tu non rispondi per spiegare, ma hai altri scopi.
Ripeto evita di rispondere.

serve.
Non ho intenzione di spiegare alcunché a chi si rivolge con un tono
decisamente sostenuto come il tuo.  Ti ho già dato gli spunti per
informarti e questo è già abbastanza.

 ha scritto nel messaggio 
news:3k6op1ttb8853jqhl...@4ax.com...

ti ripeto ancora un a volta perche' si vede che non ti entra in testa:
il punto e' che se io faccio una domanda che a te da fastidio te ne stai 
semplicemente zitto.
Ripeto ancora: io non ho chiesto a te esplicitamente e non ti sto mandando 
email private.
Ti faccio ancora notare che gli ultimi messaggi tuoi sono stati :
-"???"
-"no"
sono chiaramente arroganti, evita di rispondere la prossima volta sbruffone.

ti ripeto ancora un a volta perche' si vede che non ti entra in testa:
Ti sbatto volentieri nel kill-file, idiota.
*plonk*

 ha scritto nel messaggio 
news:9vbop1hjj1ufm06vf...@4ax.com...

Finalemente me ne sono liberato.
Ho visto che litiga spesso, poveretto... 

suvvia non litigate per una incomprensione.
il vs. argomento è molto interessante.
Se andrea cortesemente puo spiegare come esibire una interfaccia 
diversamente da quando si deriva una classe gliene sarei grato.
In Java c'è 'interface' appunto. In Delphi?
inoltre avete qualche link o letture sull'argomento MVC in Delphi?
ricordo anche il framework ECO III per realizzare quello che interessa a 
bob...
ciao e fate pace, mi offro come Adapter ;)
*fasco++;

 bob...
grazie.
Per quanto riguarda le interfacce anche in Delphi c'e' la keywork interface.
Tuttavia TDataSet non e' un interfaccia, e' una classe con molti metodi 
astratti (quindi da implementare se si vogliono uitilizzare).
Riguardo a esporre un interfaccia, io so che l'unico significato e' 
estendere l'interfaccia o implementarla, in linguaggio tecnico. 
Probabilmente stava usando un linguaggio non tecnico in quel frangente, da 
qui l'incomprensione. 

 estendere l'interfaccia o implementarla, in linguaggio tecnico. 
"Esporre un'interfaccia" significa dotare la propria classe di 
determinati metodi e attributi verso l'esterno, e questo vale sia a 
livello teorico che tecnico, in quanto questa espressione l'ho ritrovata 
spesso all'interno di volumi dedicati alla OOP che non prendevano in 
esame un linguaggio specifico e quindi non potevano fare riferimento 
diretto a caratteristiche che non sono necessariamente presenti 
all'interno di tutti i linguaggi.
Poi, che Delphi (e altri linguaggi) fornisca un particolare tipo di 
dato, identificato dalla parola chiave *interface*, che consenta di 
ottenere a livello di codice quanto illustrato sopra a livello teorico, 
è un'altro discorso.
Non capisco però l'utilità di "battere su questo chiodo" una volta 
appurato, in modo più o meno "soft" (è irrilevante) che non si parla di 
creare una classe che implementi una qualsivoglia "interfaccia Delphi" 
(figlia di IInterface, o IUnknown se preferite), bensì di creare una 
classe che derivi da *TDataSet*, ad esempio, la quale espone un set di 
metodi e proprietà che hanno un determinato significato (che può essere 
in buona parte appreso dalla Guida in linea) inserendo al suo interno il 
codice necessario per consentire che i dati esposti non provengano da 
una tabella o una query di un database, bensì da oggetti in memoria. ;-)
Da qui, poi, l'argomento si snoda e diventa molto complesso, quindi non 
è possibile esaurire la problematica in questo spazio, ma credo che 
almeno gli elementi di base ci siano; si potrebbe cominciare a creare 
questa classe, facendo ricerche mirate su Google per reperire esempi 
realizzati da altri, analizzare il codice sorgente di qualche OPF, tanto 
per valutare il lavoro fatto per un progetto che più o meno ha le stesse 
prerogative (es. InstantObjects, come già suggerito, oppure tiOPF) e 
così via.
In seguito, man mano che il codice aumenta e iniziano a verificarsi i 
primi problemi, pratici o concettuali, che devono essere affrontati, 
basta scrivere qui o partecipare a qualche forum esaurendoli 
singolarmente uno per uno.
Altro non saprei che dire... :-/
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

cosa aggiungere...se non altro che 'esporre' un interfaccia è un modo di 
dire piu' da COM e ActiveX che non OO.
Per me che vengo da C++ e java una classe 'implementa' una o piu' 
interfacce, ma non voglio dilungarmi sul verbo utilizzato basta intendersi.
Pero' devo dire Marco che una classe che implementa una interfaccia 
implementa solo i metodi e non gli attributi, e bob, che una classe 
implementa una interfaccia non la estende. Se si estende una interfaccia 
  tutte le classi che attualmente la implementano *devono* adeguarsi. In 
corba si chiamano stub se non erro.
Una classe è estesa da un'altra.
Implentare una interfaccia ed estendere una classe sono due concetti 
diversi. Per esempio, in alcuni linguaggi una classe può essere estesa 
solo da una singola classe, non è consentita l'ereditarietà multipla. 
Mentre interfacce multiple si posso implementare.
l'uso delle interfacce riduce l'accoppiamento (decoupling) tra le classi 
migliorando il riutilizzo delle stesse oltre a proteggere meglio i vari 
sottosisitemi e layout del software (persistence, object model, 
presentation etc.) oltre ad una piu' semplice lettura del codice stesso.
Se c'è un forte accoppiamento, per esempio, tra due strati software come 
il modello dati e quello della persistenza (come nel caso che si 
proponeva a bob) sarà necessario comprendere bene entrambi i domini e 
anticipare gli effetti di interazione di eventuali modifiche apportate a 
uno dei due domini.
forse mi sono allungato un tantino...
Ma in delphi è possibile implementare piu' interfacce?
se si come?
*fasco++;
p.s. sono d'accordo con bob che il termine component db-aware ormai ci 
sta stretto. considerato che il data provider come ricordava Andrea puo' 
non essere un DB. forse mda-aware?
Marco Breveglieri ha scritto:


 se si come?
Basta elencarle nella dichiarazione della classe... (e ovviamente 
implementarne i metodi). :-|



Beh insomma non so se ho voglia di mettermi a studiare i sorgenti di un 
framework..
Sicuramente ti da un qualcosa in piu', ma non penso sia la soluzione 
intrapresa da tutti coloro che vogliono usare mvc. Dovrebbe essere una cosa 
semplice se i componenti sono stati progettati bene, e sono sicuro che e' 
cosi'.
Comunque dici che qui sono preferite discussioni tecniche piuttosto che 
pattern di programmazione?

>e bob, che una classe implementa una interfaccia non la estende.
un interfaccia puo' estendere un'altra interfaccia. 

 ottimale.IMHO.
Sto provando ora con questa architettura:
dbgrid  --- datasource  --- clientdataset.
Il ClientDataSet puo' lavorare tranquillamente in memoria ad esempio:
cds.CreateDataSet;
cds.Open;
cds.Appen;
cds.FieldByName('name').AsString := 'ciao mondo';
cds.Post;
aggiunge in memoria una stringa "ciao mondo" nel campo "name". Il dbgrid si 
sincronizza tranquillamente.
Con questi presupposti una classe manager puo' tranquillamente "scrivere" e 
"leggere" dentro il ClientDataSet gli oggetti voluti.
Interessante anche il fatto che si puo' avere:
dbgrid  --- datasource  --- clientdataset --- datasource --- dataset(es. 
tabella di database)
In questo modo dentro gli eventi del ClientDataSet e non solo,  puoi gestire 
il dataset che quindi funge da potente strumento per operare con la base di 
dati (non devi scrivere per forza query sql pallose). 

 inoltre avete qualche link o letture sull'argomento MVC in Delphi?
http://www.joannac.btinternet.co.uk/
 Qui ci sono articoli interessanti
su MVP e OPF.
-- 
guastatore
ICLDweb: 
http://www2.samatel.com/icld/

 tabella di database)
scusa, il secondo datasource mi e' scappato...