Newsgroup: it.comp.lang.delphi
Titolo: Datamodule, datasource e DLL

Nella ditta in cui lavoro (da relativamente poco) abbiamo sviluppato un
programma gestionale in Delphi 5.
Chi mi ha preceduto ha utilizzato delle
DLL per riporvi svariate funzioni. Tra queste funzioni, naturalmente ce ne
sono diverse che devono lavorare sui dati, ed il problema maggiore risulta
il fatto che se per esempio la funzione deve accedere a 10 tabelle, occorre
nella lista dei parametri passare 10 datasource. Al di la del fatto che
questo ha portato ad avere funzioni e procedure con liste di parametri
CHILOMETRICHE :-(, l'aspetto peggiore è che una semplice richiesta di
implementazione che richieda l'aggiunta di una tabella, o la semplice
modifica di una funzione con necessità di leggere dati da una tabella non
inizialmente prevista, richiede la modifica della dichiarazione della
funzione con conseguente ricaduta su tutte le chiamate, le dichiarazioni,
ecc.
A questo punto mi sorge il dubbio che il nostro modo di passare i
parametri alle funzioni in DLL sia sbagliato e che sia più corretto passare
direttamente il Datamodule (o un puntatore ad esso)...
Voi come fate ?
BrunoS
--------------------------------
Inviato via 
http://usenet.iol.it

 direttamente il Datamodule (o un puntatore ad esso)...
In generale, l'alternativa Borland alle DLL e' il package (BPL).
cmq, non sono certo di aver capito quale sia il problema specifico: hai
un dm nell'exe con dei dataset che passi a funzioni della dll per
estrarre dei dati, farci dei conti e tornare un risultato?
Se il problema sono le liste di parametri non mi pare tanto grave, se si
e' scritto decentemente il codice (parametri e tipi con nomi
significativi, nomi dei metodi _parlanti_).
Se il problema e' la rigidita' ai cambiamenti credo che sia piu' grigia,
e spesso la soluzione alla fine meno dolorosa e' la riprogettazione con
conseguente riscrittura.
Saluti
Paolo Arosio

....
Facciamo cosě: provo a spiegarmi
meglio. Il mio post prende spunto da un'altro thread (non mio) passato
qualche giorno fa, riguardante la migliore soluzione per spezzare un grosso
progetto gestionale in tanti piccoli.
La soluzione suggerita dalla
maggioranza č quella di creare un EXE di base con menu e Datamodule, e poi
di suddividere in alcune DLL le varie gestioni (tipo una DLL per anagrafica
articoli, una per anagrafica clienti, una per fatture e cosě via...). Cosě
facendo, perň, si pone il problema di fornire l'accesso ai dati alle varie
procedure e funzioni poste in libreria, che č un problema simile al mio.
Posto che passare come parametro tutti i datasource necessari č
problematico (sopratutto quando le specifiche cambiano tutte le settimane
:-( ), la domanda č: c'č una soluzione diversa ? E' accettabile passare
tutto il datamodule (magari solo il puntatore) ? 
Spero di essermi
spiegato meglio.


 tutto il datamodule (magari solo il puntatore) ?
Personalmente, sto passando da un uso di Delphi procedurale ad uno che
sfrutta (anche se non al massimo) il paradigma dell'oop: tendo a
modellare i dati che mi servono all'interno di oggetti (sto parlando di
applicazioni *non* di tipo gestionale) in grado di effettuare semplici
operazioni su di essi.
Tendenzialmente, ciascuna istanza di ogni tipo di oggetto puo' essere
identificata da un insieme di attributi. Quando ho bisogno di un nuovo
oggetto me lo creo, lo modifico e se devo lo passo ad una istanza di
un'altra classe che me lo salva su supporto permanente ed e' poi anche
in grado di ricaricarlo.
Tale classe normalmente risiede in un dm ed ha conoscenza con la classe
degli oggetti che devono essere caricati/salvati e con un meccanismo di
streaming (ad es interbase, o ado, o il file system).
A questo punto il dm esporta, oltre alle proprie proprieta' published,
che pero' non devono essere usate, i metodi di caricamento/salvataggio
degli oggetti.
La mia UI tende quindi a non vedere *mai* non solo il supporto di
memorizzazione, ma neanche il meccanismo di accesso ai dati; normalmente
viene popolata tramite collezioni, liste o istanze delle classi da
rappresentare. Anche qui, la form di visualizzazione mette a
disposizione metodi set/get che hanno per parametro la classe da
rappresentare / recuperare dopo l'eventuale modifica operata
dall'utente.
Se l'applicazione e' interamente delphi (o BCB?) puo' essere
consigliabile usare, invece delle dll, i package, che consentono di
esportare non solo funzioni ma anche le classi.
Sui ng di Cantu' ci sono un paio di thread interessanti a proposito del
progetto di un gestionale os nell'area libero.kylix.generale.
Saluti
Paolo Arosio

Paolo Arosio
Ciao e grazie.
Bruno
