Newsgroup: it.comp.lang.delphi
Titolo: Per soli Esperti di OOP

Ciao a tutti,
volevo chiedere un consiglio .
Ho un'applicazione che per adesso usa come Database il DB2 vers.7.
Ma vorrei fare in modo che se un giorno volessi cambiare database non dovrei
cambiare
niente all'interno del mio progetto (poichč usate solo query ANSI/SQL) .
Avevo pensato di implementare degli oggetti esterni (anche DLL) per tale
gestione simile un pň agli oggetti COM+.
Tali oggetti o librerie, penso, che dovrebbero contenere solo gli oggetti di
piů basso livello
come per esempio il TSQLQuery della libreria DBExpress o il TADOQuery della
libreria ADO.
Ma non so neanche io effittivamente come si dovrebbe fare una cosa del
genere e se effettivamente conviene.
Perciň chiedo un consiglio a voi ESPERTI !!!!!
Ciao
RLB
--------------------------------
Inviato via 
http://usenet.libero.it

Non so se sono un esperto, cmq ti rispondo lo stesso.
Allora, per risolvere il problema ci sono vari modi.
Uno sarebbe quello di usare l'IProviderSupport.
Un'altra quella di creare un layer aggiuntivo base e
poi istanziare le classi "vere" a runtime caricandole
dai package, quindi cambiando package cambia il
DB che c'è sotto.
Oppure usare DataAbstract, per maggiori info
guarda su 
http://www.remobjects.com?da
 .
Ciao
Andrea

 guarda su 
http://www.remobjects.com?da
 .
Per questo ci sentiamo dopo, leggo prima l'articolo


gestione simile un pò agli oggetti COM+.
Secondo me non conviene mai sparare alle mosche coi cannoni.  
Non ha senso, a mio avviso, mettere in piedi un sistema modulare cosi`
flessibile, addirittura basato su oggetti COM+ e/o DLL.  D'altronde
non penso che il cambiamento di DBMS sia cosi` frequente per
un'applicazione, generalmente si fa molto sporadicamente e, al limite,
ricompilare il programma e distribuirlo non rappresenta un grande
problema.  In un certo senso, il fatto che tu abbia pensato alla OOP
mi consola ;-).  Io credo che faresti bene a isolare la parte
logico-funzionale del programma da quella di accesso ai dati mediante
classi o costrutti simili (tipo Business Objects, per intenderci).  
Per farti un esempio banale, avere una classe TCliente, con dei metodi
precisi per la lettura e il consolidamento su DB potrebbe aiutarti
molto ad isolare l'implementazione.  Quando sarai costretto a
cambiarla, le modifiche avranno impatto su una piccola parte del
codice.
-- 
Andrea Laforgia
#exclude <windows.h>

 classi o costrutti simili (tipo Business Objects, per intenderci).
Ma questo le mie applicazioni già lo fanno.
SE ti venisse fatta una richiesta del genere...come faresti ????


cliente.
Non capisco, la tua applicazione si adatta "al volo" ?


Io ho creato ciò che cerchi.
Praticamente uso un file .ini da cui leggo i parametri per la connessione al
database(In testa ho messo un parametro che sta ad identificare il database
da utilizzare. Infatti dopo tale parametro ci sono le sezioni che stanno a
rappresentare i parametri di connessione a + database).
Poi in una unit ho creato la classe DriverConnection che viene creata
all'apertura dell'applicazione è mediante altri parametri impostati nel file
di configurazione .ini automatizzo la gestione della connessione al
database(gestione transazioni, file log, connessione sempre
aperta/connessione da aprire su richiesta...).
E' molto carino implementare una classe del genere anche se ti porta via del
tempo. La cosa positiva è che il tuo programma non conoscerà limiti nella
gestione di database(almeno fin quando si trovano le librerie).
Ciao.

gestione di database(almeno fin quando si trovano le librerie).
Credo che il problema nel nostro amico sia di interfacciamento ai
dati, piu` che di semplice connessione al db.  Il problema, quando hai
a che fare con n DBMS diversi e` che il tuo programma deve fare le
cose in n modi diversi.  Si cercava un modo per unificare questo
procedimento.


 procedimento.
D'accordo...
Si cercava questo...



Ok, adesso che dovrebbe essere chiaro il mio problema......c'è qualcuno che
mi da una mano ???
Tralasciamo il fatto che sia utile o meno questa cosa, poi sarà il mio buon
senso a deciderlo, è possibile
che nessuno di voi ha sviluppato Oggetti esterni, DLL, Oggetti COM+ con un
linguaggio così potente
come DELPHI ?????
Non credo proprio.
La mia non è una domanda TECNICA ma più ANALITICA per chi non l'ha ancora
capito.
Il discorso è : Se un cliente un giorno venisse da voi e vi chiedesse di
implementare una procedura
che abbia la caratteristiche sopra descritte in che modo agisreste ????
Fareste una DLL avente all'interno oggetti per la connessione e per il
recupero dei dati ????
Fareste un oggetto a cui collegare il vostro programma Client ????
O ....???
Forza datemi una mano.....altrimenti che Analista / programmatori  siamo
????
RLB

mi da una mano ???
A me il tuo problema e` tutt'altro che chiaro, sta di fatto che non mi
hai risposto.  Onestamente, non capisco dove sia il reale problema.
Come ho gia` detto, secondo me non conviene mettere su un sistema di
DLL o oggetti COM, se il cambiamento di DBMS deve essere fatto una
volta ogni morte di Papa.  In quei casi si modifica la parte
essenziale, di gestione dei dati (che va isolata il piu` possibile) e
si ricompila il programma.  Questo se chiedi come si deve *progettare*
la cosa, altrimenti se vuoi costruire un oggetto COM o una DLL, in
Delphi e` molto banale farlo.


 si ricompila il programma.
Ok, adesso sono io che ho capito te.
Il mio problema è che il mio programma deve essere un pacchetto chiuso.
Dove, configurando determinate proprietà, in un file esterno, sarà possibile
dirgli a quale DB accedere.
L'utente non dovrà preoccuparsi di niente, solo di configurare tale file.
Logicamente, se volessi seguire la tua idea, e quindi ricompilare il
progetto per un determinato DB,
un giorno mi capiterà di avere N PROGETTI DIVERSI (ma che fanno la stessa
cosa) per N CLIENTI.
E se dovessi fare delle nuove versioni, delle modifiche, le dovrei fare N
VOLTE !!!!!!!!!
Questo non credo che sia il modo migliore di programmare.. VERO ??????
Perciò la mia domanda è ancora...come progettarlo ????
RLB

cosa) per N CLIENTI.
No, avrai solo N  moduli distinti (tra l'altro e` presumibile che
questo N valga 1, 2, o 3, massimo), ognuno contenente il codice di
basso livello per la gestione di un particolare DB, il che non e`
affatto un grande problema, anzi.  La parte logico-funzionale del
programma rimane identica in tutti i progetti.


Ciao,
stai attento che DBExpress è stato pensato proprio per fare quello che
vuoi tu: cambiare il solo riferimento ai "driver" da usare e passare
da DB2 a Oracle a MSSql ecc.
Ciao, Rocco.

 programma rimane identica in tutti i progetti.
Ok, basta, accetto la tua versione.
Ma cerchiamo di ragionare un pň.
I miei programmi, hanno vari DataModulo per la gestione dei dati.
Bč, non č che mi piaccia tanto !!!!
Tu come mi consigli di strutturare la mia applicazione ?????
Ciao
RLB



Secondo me la risposta è nel primo reply che Laforgia ti ha fatto, e che non ripeto
per evitare prolissità in questo thread...
Se vuoi proseguire per questa strada, fai pure, ma (imho) non e' la strada migliore ....
Cioe', è impossibile ipotizzare uno sviluppo come quello che vuoi tu escludendo la manutenzione.
Anche al solo livello DB.
Se tu fai una dll e ci piazzi l'interfaccia per accedere alla base dati, con un buon costrutto
ad oggetti, allora se cambia il db non dovrai fare altro che cambiare una dll del tuo progretto.
Ma creare uno sviluppo "chiuso" come dici tu, non e' impossibile ma allo stesso tempo non è 
auspicabile.
Almeno questo è il mio punto di vista....
Ciao!
Morde.
morde [at] programmer [.] net

Avevo detto CLIENTI non CLIENTE con DB differenti !!!
Appunto.  Questo avvalora il fatto che e` meglio ricompilare il
programma per un cliente e per un altro.  E bada che non significa
avere N versioni distinte del programma, ma N moduli di basso livello
per l'accesso e la gestione dei dati.


No, non ci siamo.
La Forgia mi ha detto che fare un qualcosa esterno (DLL) è inutile.
Sono io che dico di voler fare una cosa del genere !!!!
Ragazzi cerchiamo di capirci.
Nell'ultimo POST ho detto che mi sta bene seguire la strada di La Forgia,
cioè creare
moduli differenti all'interno del progetto.
Le mie applicazioni precedenti hanno sempre avuto la gestione dei dati
separata dalle altre.
Ma vorrei fare, seguendo i consigli di Andrea, un qualcosa di più Object
Oriented...
Se invece, qualcuno (Morde), vuole darmi una mano nel sviluppare il tutto
con una DLL, ben venga !!!!
Però, cerchiamo di metterci d'accordo e seguire un'unica strada !!!
Ciao e ancora grazie per il vostro interessamento!!!
RLB


Oriented...
Evidentemente non leggi i messaggi. 
Ti ho gia` detto, nel primo post, che secondo me usare una tecnica
come quella dei Business Object e` la strada migliore.


Oriented...
DUnque, vediamo di chiarirci :-)
Io intendevo dll come dire modulo, questo perche' evendo già sviluppato
un progetto business obj in c++, il modulo di interfacciamento al db era appunto una dll.
quindi scusami se ti ho confuso le idee... 
Tornando al focus: va bene sviluppare un'interfaccia al db usando gli oggetti, come fare
un modulo simile all'interno di progetto dovresti chiedere a Laforgia, perche' io in delphi ho solo
fatto programmi molto semplici senza utilizzare "business logic" a questi livelli. (ed e' un vero
peccato).
Quanto alla disponibilità, sono spiacente ma non so quanto potrei aiutarti: sono impegnato su diverse
cose al lavoro, mi sto formando su php e opensource, e sto mettendo giu' una bozza di FAQ di questo
ng.... non pensare che mi sto tirando indietro: la cosa mi stimola assai, ma davvero non ce la faccio
a stare dietro al lavoro, al ng, alla formazione, in 10 ore al giorno...
Ovviamente se continui a seguire il ng, non sara' difficile fare il possibile per starti un minimo dietro.
Ciao!!


 codice.
Forse Rino vorrebbe capire un po' come organizzare il livello intermedio dei
tre famigerati User, Business e Data: cosa far appartenere a tale livello,
come scrivere le classi contenute in esso, se creare un oggetto COM+ o
cos'altro.
Faccio un esempio:
Ho una classe TCliente. La classe ha tante proprietà per conservare i dati
del cliente ed un metodo SalvaCliente che scrive il record in una tabella.
La cosa è molto semplice e a lavoro terminato mi trovo solo un eseguibile
che contiene una form e la mia classe (oltre al database).
Come andrebbe progettata la cosa con Delphi se volessi strutturare il tutto
utilizzando tre livelli distinti?
Mi rendo conto che forse l'esempio è troppo banale, ma ponderiamo tutti gli
aggravi che nascessero da una casistica reale e ben più complessa.
Probabilmente interesserebbe sapere cosa toccare del Bisiness Level,
isolando e lasciando inalterati gli altri due livelli, laddove la tabella
dovesse risiedere su databases differenti. Forse nel caso di una singola
tabella non ci sono differenze particolari ma col colmplicarsi delle cose
magari si.
Magari sarebbe molto utile anche a me apprendere la cosa da chi ha più
esperienza.
Saluti
Giuseppe Vitali

"Morde" ha scritto nel messaggio
| e sto mettendo giu' una bozza di FAQ di questo ng....
http://gpi.infomedia.it/abc/delphi/FaqDelphi.txt
Magari andrebbe postata un po' piu' spesso ...
--
Ciao.
ACSH
[D4]
---------------------------
Chi fa da se'
fatica il doppio

Magari andrebbe postata un po' piu' spesso ...
Il link è broken, c'e' sempra la copia su google, ma io stavo facendo un lavoro diverso: infatti 
dovro' contattare MSX a questo proposito.
La mia idea è di fare le faq di it.comp.lang.delphi come le trovi qui: 
http://php.dopoil.com/
Sono già in possesso dei sorgenti php, e ieri notte ho finito di testare una altro modulo
per la colorazione dei sorgenti delphi. Quindi, è quasi tutto pronto per partire.
Devo appunto contattare MSX per l'autorizzazione a replicare le faq integrandole con contenuti
piu' aggiornati (probabilmente molti links sono scaduti...)
A breve postero' un articolo dove invito chiunque volesse ad offrire la propria collaborazione.
Spero di far qualcosa di bello e utile, in questi mesi di frequentazione mi sono accorto di 
quanto l'esperienza che hanno alcuni di questo ng sarebbe utile al gruppo!
C'e' gente che lavora da anni con delphi sui databases, sull'automazione, sul web: è una miniera
di esperienza di inestimabile valore!
Ok, questo per chiarire il punto delle FAQ.
Se qualcuno e gia' in contatto con msx oppure egli stesso legge ancora il ng, sarebbe bello
tornare a leggerlo...
Ciao!


 
http://gpi.infomedia.it/abc/delphi/FaqDelphi.txt
ho provato ad arrivarci ma non risponde...
