Newsgroup: it.comp.lang.delphi
Titolo: Datamodule come si usa, mi sfugge qualcosa?

Riesco ad usarlo, ma non capisco come farlo in modo proficuo.
Cioè:
Per centralizzare le info di connessione DB ho provato ad utilizzare un 
datamodule
ma non capisco bene come implementarlo.
per esempio:
1) metto un TIBDatabase,TIBTransaction,e un TIBDatasetAUTORI
2)sviluppo una form cerca autori con una grid collegata alla variabile 
IBDS_AUTORI derivata dalla classe TIBDatasetAUTORI
3)faccio in maniera che la mai form possa lanciare N istanze separate della 
Form
L'effetto che ottengo e che le grid nei vari componenti sono sincronizzate, 
ed è anche "OVIO"
visto che in realtà utilizzano proprio la variabile "IBDS_AUTORI" e non una 
variabile autonoma creata dalla classe TIBDatasetAUTORI .
Ne deduco che se voglio le griglie indipendenti su due istanze della stessa 
finestra devo spostare
il dataset (e immagino anche la transazione) dentro alla form.
Ma allora a cosa serve il DATAMODULE?
Specifiche dei componenti utilizzati nella prova
D2007
Motore DB Firebird
componenti DB utilizzati "interbase"

 il dataset (e immagino anche la transazione) dentro alla form.
Form + relativo datamodule, da creare alla creazione della form e da
legare al datamodule contenente SOLO la connection.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Il DataModule serve per cenrtralizzare delle operazioni da fare SEMPRE sui 
dati
Basta guardare la parte eventi e scoprire quante cose utili ci sono 
dietro...
C. 

 Ma allora a cosa serve il DATAMODULE?
In alcuni casi, il "sincronismo" è anche accettato e volutamente 
ricercato: dipende dall'architettura che implementi.
Ad ogni modo, in relazione all'accesso ai dati, puoi sempre disporre 
solo il componente per la connessione sul DataModule, e lasciare i 
DataSet sul Form specifico.
Il DataModule, poi, può contenere qualsiasi tipo di componente (es. 
ImageList) che può essere così condiviso in tutta l'applicazione, non 
solo quindi componenti per l'accesso ai dati.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

ImageList) 
Nahhh. Discordo anche su questo. Se le ImageList sono destinate a
contenere liste di immagini da usare su particolari form, è bene che
stiano su quelle form (model con model, view con view, controller con
controller). Se vanno condivise tra più form, vuol dire che c'è un
legame logico tra quelle form, quindi si usi la VFI. 
Gli IDE come Delphi tendono purtroppo a mischiare i concetti preziosi
del modello MVC. Nulla vieta, d'altronde, di avere una form con il suo
bel, personalissimo datamodule.

 bel, personalissimo datamodule.
Nulla vieta nemmeno, d'altronde, che ci sia il Form col suo DataSet, 
senza un DataModule. :-)


senza un DataModule. :-)
Lo vietano le regole di buona programmazione. Ma tu sei libero di fare
come ti pare ":-)".

Prima di tutto faccio pubblica ammenda.
Stavo lavorando su un computer ospite e non sono abituato ad outlock.
Per errore ho risposto in privato e non sul NG
Riposto anche sul NG le risposte che avevo dato in sequenza
Camperos
Laforgia
Breveglieri
Anche se adesso non sono piu sicuro di condividere quello che ho scritto.

progetto che non ho tempo di spiegare.
Ma infatti a me non interessa il TUO progetto che non hai tempo di
spiegare. Come ho già detto, sei libero di fare quello che vuoi. A me
preoccupa che altre persone possano apprendere tecniche sbagliate e
quindi consiglio quelle corrette.

 dietro...
eventi del datamodule?
Solo:
    oncreate
    ondestroy
Continuo a non capire!
Per ora ho lasciato nel datamodule solo la connessione al DB
il Dataset e la transaction l'ho messa sulla form.
L'applicazione è veramente banale, prevede 2 Form che lavorano sul DB (più
forse 2 per le ricerce) e la uso per imparare. Almeno se decido di cambiare
radicalmente tutto con solo 2 form si fa abbastanza presto:-).
Sto scrivendo l'applicazione e vedendo il codice che mi tocca duplicare con
copia incolla (appunto quello che dovrebbe venire centralizzatto in un unico
punto)
Per ora c'è quello della gestione delle varie stringhe SQL, che ho messo sul
datamodule, ma potevo benissimo metterle in una unit non visuale (anzi penso
che lo mettero in una unit standard).
l'altra cosa che ho fatto è una classe TmyDBForm che contiene a livello non
visuale una property di tipo "transaction" e una "dataseet" (al momento
questo mi e sufficiente) cho la definizione di alcuni metodi comuni.
poi ho cambiato le form in maniera che derivino da questa.
NON CAPISCO, Ho la continua tentazione di eliminare completamente i
riferimenti al DB come componeti visuali e gestire il tutto da codice!!!
certamente qualcosa mi sfugge. 

Questo perchè al momento non ho capito come si utilizzano,
Ti è stato già spiegato.

allora metti tutto insieme e te ne sbatti.
Anche nel caso di un'applicazione "piccola" si possono adottare
tecniche di separazione dei ruoli. Anche perché se si adottano sempre
approcci minimi, si finisce per non conoscere mai quelli adatti a
progetti piů corposi.

non abbia capito nulla)
Sě, non hai capito nulla.

 legare al datamodule contenente SOLO la connection.
Scusa, non riesco a capire. Se ogni form che si interfaccia col DB deve
avere il suo datamodule
non ne vedo lo scopo. metto 2 componenti in più sulla form e sono a posto.
anzi, creo una classe form che contiene quei 2 componenti e derivo la mia
form da quella.
Non sono riuscito a trovare degli esempi che mi chiarissero l'utilizzo.
Nella risposta che ho dato a camperos si vede che ho quasi rinunciato hai
datamodule.
Questo perchè al momento non ho capito come si utilizzano, ma visto che
l'applicazione è piccola, adattissima per imparare, se riesco a capire come
fa faccio presto a riconvertirla all'uso del datamodule.
PS!!! PROPRIO NON MI TROVO CON OUTLOCK PER ERRORE HO NUOVAMENTE ROTTO LE 
SCATOLE IN PRIVATO AD ANDREA ANZICHE POSTARE SUL NG. MI SCUSO CON LUI 

 sul Form specifico.
Al momento è quello che ho fatto.
Però sono rimasto deluso, prima di usarlo le potenzialità mi erano sembrate
maggiori.
E' anche vero che se l'applicazionerichiedesse solo una singola vista per
volta dei dati
andrebbe benissimo. Penso a cose fatte a wizard oppure applicazioni a
finestra singola in cui
tramite tab o altri sistemi cambia il contenuto della finestra.
Però non mi sembra che la maggior parte delle applicazioni che appoggino su
database si possano adattare facilmente a questo tipo di interfaccia.
Tra l'altro "Marco Breveglieri" fa parte dei nomi di cui ho grande
considerazione e
la tua risposta (se non ho male interpretato) mi conferma che l'idea che
avevo del datamodule
va ridimensionata.
Non so se sviluppi applicazioni database, ma nel caso, se posso permettermi,
Li usi?
Sinceramente, ora ho eliminato la parte visuale dei componenti di
connessione.
e gestire la creazioni delle stringhe di  select,insert,delete,update da
codice mi sembra molto più portabile e flessibile. (Possibilissimo che io
non abbia capito nulla)
L'unicà utilizzo che è rimasto dei componenti visuli è una copia "MORTA" NON
gestita e da ELIMINARE alla fine per darmi un aiuto visuale nella creazione
del codice.
Spero di trovare una buona architettura di progetto. Finchè ho a che fare
con programmi banali.

"BC" <no...@none.none> ha scritto nel messaggio 
news:_40dk.112980$FR.3...@twister1.libero.it...

Ciao
supponiamo di avere un'applicazione complessa, diciamo 40 form con 10 
tabelle incrociate tra loro
con controlli  before e after post, magari anche con proprietà delle colonne 
settate, ad esempio
mask di edit e di output ecc..., campi calcolati che usiamo *sparpagliati* 
*su* *tutte* *le* *form* dell'applicazione.
Dove la metti tutta 'sta roba ripetuta ? Indovina ? Controlli, procedure, 
if.. ecc..
Se invece hai una piccola applicazione composta da UN form e UNA tabella 
allora metti tutto insieme e te ne sbatti.
Ma un'applicazione con un form è proprio un caso particolare....
Il DataModule serve proprio a "concentrare" tutto in un posto unico, per 
ovvi motivi di leggibilità e manutenzione.
Mò basta, però....
C.

OK, Ho capito che li usate, quindi devono essere utili è io sto sbagliando!
(sospetto che avevo anche all'inizio, altrimenti non aveva senso farli.)
La mia esperienza è limitata utilizzo un delphi in "prestito estivo" (quando 
tutti gli effettivi torneranno a lavorare dovrò provvedere diversamente, ma 
credo di avere 3 mesi di tempo)
+ un manuale D2006 di Marco Cantu trovato usato. Volevo valutare se sono 
ancora capace di programmare è anche come mi trovo con delphi. Ho una 
possibile realizzazione per un ottica che potrebbe anche valere 
l'investimento di acquistare delphi.
Comunque il progetto che ho realizzato per medico di base "a gratis"  (Manca 
ancora la stampa) era probabilmente "troppo semplice" per cui ho avuto 
l'impressione che la sovrastruttura fosse inutile e che non fosse necessario 
fare un dataset per ogni form (suggerimento di Andrea, almeno il primo 
suggerimento che ho letto). probabilmente appena mi capita di realizzare una 
form che richieda in numero superiore a 1 di tabelle mi verra da dire... A 
si, qui era meglio fare cosi.

 come ti pare ":-)".
Di regole di buona programmazione, di metodologie e altre cose affini ne 
esistono a migliaia, a volte anche in contrapposizione tra loro, dalla 
più semplice e immediata, con relativi pro e contro di ciascuna.
Personalmente, scelgo delle soluzioni cercando di valutare tutti gli 
aspetti del caso; poi, potrò ovviamente anche sbagliarmi a conti fatti, 
ma ignoro completamente il tuo giudizio sulla presunta violazione delle 
"regole di buona programmazione" a priori, che non tiene conto dei 
fattori sconosciuti, astraendo da qualsiasi realtà pratica applicata al 
progetto che non ho tempo di spiegare.
Ciao,
   Marco.



Ciao
forse proprio qui č il tuo dubbio.
Normalmente la stessa tabella si usa su piů Form, per questo si centralizza.
Ad esempio un'anagrafica ...: inserimento fattura, stampa fattura, ecc.
C. 


Si, ma... no non ho capito, prima credevo di aver capito, ma ora non più.
Prendo l'esempio della fattura.
Ok, Fattura e stampa sono comodissimo ad avere la perte del database 
centralizzata nel datamodule.
MA, io voglio lasciare la possibilità di aprire 2 o più fatture 
contemporaneamente.
Quella attuale che sto inserendo e una vecchia in consultazione perche 
voglio vedere cosa avevo venduto ultima volta a questo cliente.
Quindi nel mio programma vado sul menu e faccio partire una altra istanza 
della mia movimentazione per la fattura.
Purtoppo da come l'ho capito io le 2 form avranno in cumune le stesse 
variabili globali
che sono definite nel datamodule. Comodo perchè mi prende gli stessi valori 
che ho inserito
nell'editing del componente e mi risparima di scrivere qualche riga di 
codice, ma come effetto collaterale ha che i contenuti delle 2 form sono 
legati.
Mi punteranno alla stessa variabile Globale 
ibDatasetTestataFattura,ibTransactionTestataFattura
ibDatasetSoggetti ... ibDatasetListino, ibDatasetValuta, 
IbdsTipodocumento,IbdsMagazzino Eccetera Eccettera, e sono un bel po' 
considerando anche il corpo e il piede
quindi se uno di questi valori si sposta sulla form A, viene modificata una 
delle veriabili globali comuni e la modifica viene riprodotta anche sulla 
form B.
Io l'unico modo che ho trovato per "evitare questo comportamento" è mettere 
il componente all'interno della form. in questo modo viene caricato come 
proprietà e risulta "LOCALE" ad ogni singola istanza di quella form. Solo 
che così ho saltato il datamodule.
In questo momento mi sento bloccato. Se chi ha più esperienza di me usa con 
prifitto i datamodule, vuole certamente dire qualcosa.
Sono Confuso.

legare al datamodule contenente SOLO la connection.
probabilmente era la risposta che cercavo, solo che mi era risultata
criptica. 
Googleggiando in effetti ho trovato questo esempio...
http://www.ipsiamoretto.it/utenti/azzani/public_html/corso-delphi/capamain.htm#data_module_e_riusabilita
procedure TFormArticolisti.FormCreate(Sender: TObject);
begin
  MyDataModule:=TDataModuleSchema.Create(Self);
  DBGrid1.DataSource:=MyDataModule.DataSourceArticolisti;
end;
(peccato che dal sito non mi funziona lo scarico dell'esempio
completo)
Mi sembra che  sia l'equivalente esatto del tuo suggerimento.
Dimmi se ora sono vicino alla soluzione:
1) Levo dal progetto la creazione automatica dei datamodule
2) dentro la form creo i componenti Data-Aware collegandoli alla
variabile GLOBALE definite nel datamodule. Così in fase design time
posso utilizzare gli aiuti visuli 
3) in fase di creazione maschera istanzio un datamodule che ora è solo
di questa istanza della maschera.
4) lo collego, (li collego, quà spesso saranno più di uno)
Domani provo 'sta soluzione. Forse è la volta buona che ho capito.

4) lo collego, (li collego, quà spesso saranno più di uno)
Funziona. con l'utilizzo del datamadule e circa come voglio io.
Ringrazio Laforgia, Breveglieri e Camperos perle spieazioni fornite.
Ancora una cosa però.
Per implementare questo ho dovuto fare in maniera che
la variabile "MyDataModule:TDataModuleSchema" fosse definita come
proprieta della form.
Quindi
1) ho editato il codice è l'ho aggiunta manualmente
2) ho dovuto spostare la uses del mio datamodulo sotto la sezione
interface e non come fa delphi (use unit alt f11) che la mette sotto
la sezione implemantation.
Queste 2 modifiche manuali non mi danno noia, ma il doverle fare
mi mette il sospetto di aver ancora pisciato fuori dal vaso.
Comunque grazie ancora per l'aiuto.