Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Sfruttare bene l'OOP

Allora, supponiamo. Ho una classe Persona con tutte le sue brave proprietà
Cognome, Nome, Sesso, Codice Fiscale, i dati sulla nascita
e così via
Ho realizzato un metodo .IMPORTA, che prende i dati dell'oggetto Persona e
li inserisce in un database.
Questo per cercare di rendere il più possibile indipendente la classe del
resto dell'applicazione: così facendo il programma chiamante non è obbligato
a connettersi al database.
La procedura istanzia la classe, la riempie leggendo dati da un file di
testo, poi lancia il metodo e mi ritrovo la persona nella tabella che
voglio.
Ok, bene. Ora supponiamo che abbia una collection di 50 elementi. Ogni
elemento contiene un oggetto Persona diverso, ognuno con i suoi dati, e
ognuno CON LA SUA CONNECTION e RECORDSET....
le risorse sono assurde, o sbaglio?
Non solo, anche le prestazioni credo lascino a desiderare. Se faccio:
For i=1 to MyCollection.Count
 MyCollection(i).IMPORTA
Next
io importo le 50 persone in tabella, ma ogni volta che lancio il metodo
IMPORTA apro e chiudo la connection.
Voi come organizzereste questa cosa?
Io ora, banalmente, ho messo la ADODB.Connection globale nel progetto e
quindi risolvo usando la stessa dentro il metodo, ma è la via più giusta e
corretta?
Questo secondo me fa parte "incapsulamento": il funzionamento del metodo è
dipendente dal resto dell'applicazione. Quest'ultima infatti deve aprire la
connection, e solo allora il metodo funzionerà...
mah, lo so che c'è il weekend, ma voi cosa ne pensate?
good coding!!!
-- 
Damiani Liborio Igor
http://www.igordamiani.it
Nella finestra Debug di VB:
Nome="igor":? Nome & Chr$(64) & Nome & "damiani" & Chr$(46) & "it"
Che tu sia maledetto, SWEN...

 Next
Finito l'INSERT di tutta la collezione
chiudo la connection.
Aprire e chiudere, oltre a risorse, rallenta la lettura sequenziale del
codice.
Tra l'open e la riga di codice successiva c'è un rallentamento
Ave
giuseppeD

 Voi come organizzereste questa cosa?
[SNIP]
Dipende...
come ti ha suggerito Giuseppe, potresti aprire la connessione all'inizio del
ciclo e chiuderla al termine; per mantenere la maggiore indipendenza
possibile della classe, potresti aggiungere al tuo metodo .Importa un
parametro opzionale di tipo Connection: in questo modo la classe si mantiene
autonoma (se non passi una connessione aperta la crea come fa gia' ora) ma
puoi ottimizzare procedure "bulk" come questo.
Un altro sistema, leggermente piu' elaborato ma secondo me piu' elegante, e'
quello di creare l'insieme 'Persone' ovvero una tua collection tipizzata; a
questo punto puoi definire il metodo Persone.Importa che lavora sull'intero
insieme aprendo una sola connessione, lasciando comunque il metodo
Persona.Importa per le operazioni atomiche.
Per questa cosa, cioe' creare la collection tipizzata, puoi aiutarti con il
wizard per creazione classi di VB6, che tra l'altro aggiunge qualche membro
"strano" per supportare il costrutto 'for each' (poi fatta una, puoi lasciar
perdere il wizard e basarti sempre su quella...)
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 voglio.
L'idea di rendere la classe indipendente dal resto dell'applicazione è
ottima, però applicata in questo modo rischia di rendere la classe
persona poco utile al di fuori dell'applicazione stessa.
Nel momento in cui tu dovessi avere la necessità di salvare i dati in un
altro modo (un altro db, un'altra tabella, su un file di testo, ecc...)
ti troveresti a dover mettere mano alla classe.
Secondo me la cosa migliore (da approfondire meglio, ora la butto giù in
fretta) sarebbe "pensare" un'interfaccia (una classe astratta) di 
persistenza che fornisca, implementata in una classe concreta, alla classe 
persona i metodi per "salvarsi", magari lasciando alla classe persona un
modo di default da usare in caso non venga passata questa classe.
Dubito di essere stato chiaro, ma son veramente a pezzi e faccio fatica
persino a pensare...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 corretta?
Tra le varie alternative:
1) un parametro nel metodo importa (preferibilmente definito in un
interfaccia come suggeritoti da HPL) che definisca la connessione al
db da utilizzare: così facendo il compito di aprire la connessione
resta dell'applicazione, come nel tuo caso,, ma a differenza della tua
attuale soluzione, non dipendi da variabili globali che di fatto
limitano la riusabilità della classe al di fuori dell'applicazione
stessa (una sorta di incapsulamento al contrario)
2) una classe con ruolo di "gestore base dati" che fornisca tutti i
metodi di accesso tra cui apertura/chiusura connessione, import/export
dati: a questo punto il metodo importa verrebbe definito in questo
dbmanager e richiederebbe come parametro l'oggetto persona da
importare.
In alternativa puoi fare un mix delle due, ossia aggregare alla classe
persona un gestore dei dati della persona stessa: la classe persona
diventa così riusabile in qualunque contesto applicativo e l'aggregato
non è strettamente dipendente dal modello di architettura della base
dati.
HTH,
Moreno

 corretta?
Tra le varie alternative:


grazie a tutti, anche se un po' in ritardo, per i vostri post.....
c'è stato un weekend di mezzo, e mi ero addirittura dimenticato di aver
postato!!!
:-)))
fate un po' voi come sono messo....
cmq, grazie ancora, penserò all'idea migliore....
