Newsgroup: it.comp.lang.visual-basic
Titolo: "Data services" e "business services"

Ciao a tutti,
Mi rendo conto che il mio problema possa apparire un po' astratto, ma dato
che cerco esempi concreti in VB, spero che qualcuno mi aiuterà.
Sto per sviluppare un'applicazione con VB5 Pro, e vorrei applicare il
metodo di strutturazione logica dell'applicazione basato sulla separazione
tra "user services", "business services" e "data services", anche se la
struttura fisica sarà una semplice coppia ".exe + .mdb" installata su una
macchina, e utilizzata da un solo operatore.
La ragione per cui voglio applicare questo particolare approccio
progettuale è che l'applicazione dovrebbe essere facilmente evolvibile al
fine di renderla utilizzabile in ambiente Intranet, con la possibilità di
un utilizzo multi-utente. So che dovrei usare l'edizione Enterprise di VB
per realizzare una versione client/server del mio software, ma non vorrei
applicare alcuna modifica di grande rilievo alla struttura logica del
programma allorché il programma dovrà essere trasformato in un sistema
client/server.
Veniamo al dunque... ho compreso come esprimere in VB la distinzione tra
"user objects" e "business objects", ma ho dei problemi a trovare la
"traduzione in VB" della distinzione tra "business objects" e "data
objects".
Come posso definite un "business object" che sia indipendente dalla
struttura del database, e un "data object" (basato su DAO) che operi da
interfaccia tra un "business object" e i dati ad esso relativi presenti
nel database?
Istintivamente, definirei dei metodi "Write" e "Read" nel "business
object", ma come posso rendere questi metodi indipendenti dal database (e
da qualunque "linguaggio" di gestione dati, sia esso DAO, RDO, ADO,
etc...)?
L'unico documento, su Internet, che si avvicina a dare una risposta alla
mia domanda si trova a
http://www.microsoft.com/devnews/devdays/scalarch.htm
, ma mi farebbe
piacere leggere qualche altro (e/o migliore) esempio, se possibile.
Grazie a chiunque mi vorrà aiutare.
Ciao,
Giovanni


Gia' che ci siamo, mi sapresti dire dove posso trovare altre informazioni
(libri, siti, docs, faqs, etc...) su questo argomento?
--
Roal Zanazzi
z...@iol.it

(libri, siti, docs, faqs, etc...) su questo argomento?
La Microsoft ha svariate informazioni, ma in ordine sparso, e la cosa
migliore è fare ricerche per parole chiave sul sito Microsoft.
Una pagina eccellente è 
http://www.ambysoft.com/onlineWritings.html
, dove
puoi trovare i "white paper" di Scott W. Ambler, che ha anche scritto
qualche documento per Microsoft. Purtroppo però sono documenti che
prescindono da qualunque linguaggio specifico, e che quindi è difficile
applicare a VB a meno che tu non sia molto più esperto di me...
Non appena ho qualche riferimento in più, te lo farò sapere.
Grazie per la tua risposta, e spero che presto riusciremo a risolvere i
nostri dubbi.
Alla prossima,
Giovanni

che cerco esempi concreti in VB, spero che qualcuno mi aiuterà.
...
Salve io mi chiamo Bruno ed ho affrontato questo problema nelle scorse
settimane. Se dovessi spiegare quello che ho fatto in un'articolo sul
NG dovrei scrivere per i prossimi tre giorni. Non per il fatto che le
cose da fare sia moltissime ma perche la mia capacita' di spiegare
un'argomento di questi tipo tende a zero se non a -1. 
A parte gli scherzi io ho un solo suggerimento: leggete l'articolo del
libro di Deborah Kurata relativo alla gestione del database con le
classi. Il libro si intitola "Doing objects in Microsoft Visual Basic
5".
 E' chiarissimo e spiega l'architettura di una applicazione dove si
vogliono separare i dati, le procedure per farvi riferimento e
l'interfaccia utente tutto in funzione di un database. 
Quindi se ne avete possibilita' leggete il libro.
Saluti.
---Bruno

"business objects" crea dei problemi di scalabilità del software.
Mi pare ti sia risposto da solo.
Sì perché la risposta al tuo dubbio dovrebbe eseere: "I business Objects
sono classi specifiche e non oggetti di accesso ai dati".
Fattura sarà una classe con i suoi tipi strutturati (così da associarli a
recordset più comodamente) ed i suoi metodi Read e Write, Update ecc.
Se prevedi di utillizzarli in remoto nel futuro ti conviene creare oggetti
DCOM (e qui si ferma la mia effimera conoscenza). Oppure scrivi classi
normali ed in futuro apporterai qualche piccola modifica relativa alle
comunicazioni remote.
Anch'io sto strutturando un'applicazione in campo economico per un amico e
vorrei intraprendere questa strada.
Ciao
Luca

nostri dubbi.
Gia', forse prima o poi dovro' comprarmi un buon libro :-)
--
Roal Zanazzi
z...@iol.it