Newsgroup: it.comp.lang.visual-basic
Titolo: [SEMI-OT] Separare GUI e database

Ciao,
sto cercando un metodo efficace ed efficiente per slegare il più
possibile i moduli di gestione delle GUI da quelli di gestione del database.
Mi spiego..
Vorrei fare in modo che nelle classi di gestione delle GUI (quindi Forms
 e classi di utilità) si faccia il meno possibile riferimento alla
struttura del database (per esempio evitando di usare direttamente i
nomi dei campi) in modo tale che l'eventuale modifica del database
influenzi il meno possibile l'applicazione.
Solitamente utilizzo Classi separate che accedono e modificano il
database, ed avevo pensato di creare un file XML contenente la
definizione della struttura del DB (per effettuare i controlli di
coerenza) e poi crearmi un'interfaccia verso l'applicazione che
permettesse di accedere ai campi usando magari delle costanti o dei
tipi...ma non vorrei rischiare che diventasse tutto macchinoso...
Voi avete qualche suggerimento?
Tnx.
Daniele.
-- 
Free As In Freedom
www.fsf.org
http://blog.libero.it/LeleB/

 influenzi il meno possibile l'applicazione.
Io nella fase di progettazione a volte la gui proprio non la considero e
credo moltissime funzioni in delle classi di gestione db. Da quel punto in
poi, cioe' quando tutto cio' che riguarda i dati e' redatto,non resta che
chiamare quelle funzioni da un form , una pagina web o da remoto... e' molto
comodo perche' posso portare la mia app teoricamente dove voglio, sul web,
su una stand alone, chiamarla da remoto con winsock ecc...
Il problema e' che e' macchinoso nell'organizzarlo e scomodo quando devi
gestire la visualizzazione in griglie ad esempio, io mi facevo tornare un
foglio xml con anche le fortattazioni dei campi, cosi' posso usare questo
"recordset" come normale base dati oppure fargli popolare e formattare una
grid.
-- 
-Gigio@work-
G2k Blog : 
http://www.g2kweb.it/?3098
G2k Snip Url : 
http://www.g2kweb.it/?3015
G2k Free Gallery : 
http://www.g2kweb.it/?218

 possibile i moduli di gestione delle GUI da quelli di gestione del database.
Sacrosanto.
Noi usiamo tutte Stored Procedure.
Anche per una semplice Select, viene invocata una apposita SP.
Questa restituisce i dati in un determinato formato, indipendentemente 
da dove in realtà siano o come siano disposti.
La cosa è efficientissima, in quanto le SP vengono compilate e tenute 
in cache, per cui hanno performance di esecuzione altissima.
Inoltre, quando cambia qualcosa nel db, il client non se ne accorge 
neppure.
Da quando abbiamo scelto questa strada, siamo anche riusciti a 
ottimizzare le squadre, nel senso che alcuni si sono specializzati sul 
lato 'logica e db' (io sono fra questi), e altri sull'interattività 
(che poi, a questo punto, abbiamo portato in poco tempo da VB a C#, e 
altrettanto rapidamente da PC a WinCE, tanto sono maschere e 
bottoncini, oramai lato client di 'capisci' non lasciamo più niente).
Con un po' di attenzione all'uso di Sql standard, anche la portabilità 
delle SP da Sql-Server a altri dbms è rapidissima.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 Alberto
Ciao e grazie!


 Cioè? ADT, XML o cosa?
No, recordset ADO o semplici valori scalari di ritorno.


 Voi avete qualche suggerimento?
Fai come fanno tutti, cioè con le interfacce.
Giusto come esempio, considera queste tre interfacce:
IConnection
IPersistentBroker
IPersistable
la prima potrebbe avere le proprietà DataSource e Database, un metodo
ExecuteQuery(QueryString as String) ed
ExecuteNonQuery(QueryString as String).
IPersistentBroker potrebbe esporre la IConnection ed in più, per
esempio, creare una classe specifica con un metodo, tipo
function CreatePersistable(DataType as String) as IPersistable
per il DataType hai due strade:
1) L'utilizzo di una hash list di accoppiamento, puoi per esempio
    creare un singleton che "registri" un riferimento ad una certa
    classe assieme all'hash del nome della stessa.
    Quando vuoi aggiungere un nuovo dato gestibile, aggiungi un
    elemento alla lista ed hai fatto :-)
2) File XML esterno
IPersistable invece avrà tre metodi principali:
- Load(Parameters as String) che serve a fare una select
- Save che serve a fare una insert
- Update
- Delete
Il bello di questa interfaccia è che se vuoi caricare una lista di
elementi puoi farlo tranquillamente, tenendo i parametri "giusti" e
semplicemente implementando una classe che sfrutta una query
diversa ed un diverso meccanismo "interno" per la gestione del
result set.
Inoltre questo sistema ha il vantaggio di non dover per forza
avere a che fare con ADO, volendo potresti utilizzare gli
oggetti client Oracle o chissà che altro :-)
Ovviamente tutta la struttura è buttata lì, magari servirebbe un pò di
ragionamento per affinarla ma insomma... il concetto è quello :-)
Ciao,
Andrea

 Andrea
Complimenti!
Il ragionamento OO che hai fatto mi svincola dal linguaggio o tecnologia
 di implementazione!


 Daniele.
Andrea

 trovi in giro già da un pò ormai :-)
Ehehehe, bè lo so bene!! ;)
Era solo per dire che purtroppo io non avevo ragionato in 'modalità' OO!
Usare VB a volte porta fuori strada!
Infatti mi sa che per questo nuovo progetto punterò verso .NET!
Ciao!


 Infatti mi sa che per questo nuovo progetto punterò verso .NET!
Potresti dare uno sguardo a questo:
http://www.chilisoftware.net/OPFNET/
Ciao,
Andrea

 
http://www.chilisoftware.net/OPFNET/
Infatti stavo proprio cercando un OPF utilizzabile con .NET
Il più famoso penso sia Hibernate, di cui c'è un porting per .NET:
http://nhibernate.sourceforge.net/
Qui ci sono alcuni OPF opensource per C#:
http://csharp-source.net/open-source/persistence
Cmq, grazie mille!
Daniele.


 Daniele.
Andrea

 
Hai mai lavorato fin'ora con un OPF?
Facci sapere se trovi qualcosa di valido!
Ciao!
Daniele.
-- 
*******************
Free As In Freedom
-= 
www.fsf.org
 =-

 Daniele.
Andrea

 veramente generalizzato fino a livelli impressionanti, purtroppo per
Altra cosa che mi viene in mente a questo proposito: sempre volendo,
potresti costruire un programma di setup generalizzato che si legge la
configurazione(nome programma, cartelle, ecc) da un file di 
configurazione e che una volta installato tutto, semplicemente ti
chiede quali connessioni vuoi usare e di specificarle, in questo
modo potrebbe poi caricarsi gli assembly(con la reflection) generare gli
statement ed eseguirli, tutto senza che l'utente muova un dito.
Non male eh?
Peccato che, per ora, dotNET lato client sia ancora(per moltissimi
casi) una pura e semplice utopia...
Andrea

 sfugge, perché non si spiega altrimenti.
La teoria è, in effetti molto interessante...ma _forse_ si è ancora in
una fase (appunto) 'troppo teorica' e 'poco pratica', e _magari_ gli
strumenti non sono ancora così ben funzionanti?
Bye!


 Daniele.
Andrea

 punto di vista.
Ehehe...conosco qualcuno che ha fatto della compatibilità con il passato
il suo più grande punto di forza ;)
E mi sa tanto che opterò per "lui"!
Ciao!!!


 Ciao!!!
Ciao,
Andrea