Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Sto creando un mostro... :)

Ciao a tutti
vorrei porvi questo problema... magari banale, ma... :)
Sto sviluppando un'applicazione gestionale (VB6 + Access), in cui il form
principale è SDI. Da questo, tramite diversi comandi / voci di menu /
tasti / ecc. vengono lanciate altre finestre per l'analisi & la modifica
dei dati.
L'applicazione è divisa in una serie di classi che gestiscono l'accesso al
database, più una serie di finestre. Tutto Ok.
Il problema è che adesso, il form "main" sta diventando un mostro... Nel
senso che deve (da solo, poracccio...) gestirsi tutti i vari casi
(callback degli altri form: ad esempio, l'aggiunta di un nuovo cliente al
DB). Quindi vorrei snellire un po' la cosa. Come fare?
Io pensavo (ma non so se è la via giusta / migliore), di creare delle
classi, ognuna delle quali si occupa di una "sotto parte" del codice. Per
esempio: ho la tabella di clienti, da visualizzare in una griglia, e
questa classe si occupa di gestire l'aggiunta / la modifica di un cliente,
aggiornando i dati nella form principale.
No so perè che "taglio" dare all'applicativo...
Voi come fate? Che dite?
Ciao!!
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 No so perň che "taglio" dare all'applicativo...
netto, sicuramente
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo



E' successo anche a me con un programma che era nato prima come semplice
programma per scontrini. Abbiamo poi aggiunto magazzino, fatturazione,
gestione registri, ecc...  L'eseguibile era arrivato quasi a 10 MB ed allora
abbiamo deciso di creare delle DLL ActiveX "a tema". Abbiamo lasciato il
corpo del programma cosě com'era e poi abbiamo creato per esempio (i nomi
sono a caso!):
tabelle.dll --> ci sono tutte le anagrafiche
fatturazione.dll --> ci sono i programmi per la generazione delle fatture di
fine mese
magazzino.dll --> tutte le stampe e le interfaccie grafiche per la gestione
del magazzino
e cosě via...
Per far "comunicare" (nel senso di path del DB, permessi utente, ecc..)
tutti i componenti puoi usare un fili INI che metti nel path
dell'applicazione oppure il registro di sistema.
Ciao, Vincenzo

 (io c'ho capito pochino, ma sembravano interessanti
Mmmhhhh (<- leggi mumble, mumble).
Primo: grazie mille della risposta.
Ok. Qualcosina dell'architettura 3-tier l'ho capito... oppure, non ci ho
capito niente, però "quanto ho capito" è sufficiente per il tipo di
applicazioni che devo andare a sviluppare.
Il mio problema è l'architettura *a livello interfaccia*, ovvero:
- ok, ho separato il livello di accesso ai dati dall'interfaccia
- adesso, l'interfaccia non fa mai richieste dirette al DB, ma passa
attraverso una serie di classi
- però è proprio la parte di interfaccia che è (sta diventando) sempre più
complessa da gestire: parti abilitate e non, gestione degli eventi,
gestione delle modifiche al database, ecc.
Io, dopo aver scritto un bel po' di applicazione ( :( ), adesso mi accorgo
che ogni volta ho fatto in un modo diverso, per gestire le cose.
C'è qualche linea guida?
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 


 C'è qualche linea guida?
non per autocitarmi, ma...
http://groups.google.it/groups?q=dalla+quarta+in+poi+group:it.comp.lang.visual-basic+author:melchiade+author:bedrosian+author:baol&hl=it&lr=&selm=327k1fF3hsfvsU1%40individual.net&rnum=1
:-)
-- 
Salutoni
Sergio
Per rispondere... togli il group dall'indirizzo
questo articolo e` stato inviato via web dal servizio gratuito 


 fatturazione.dll --> ci sono i programmi per la generazione delle fatture di
fine mese
Quindi, tu suggeriresti di dare un taglio funzionale alla cosa? Ok.
Perň, il mio problema č (anche) il seguente: ok a spezzare il programma in
tante DLL, perň come fare _architetturalmente_ per farle comunicare?
Voglio dire: dal tuo esempio, sembra che nessuna delle DLL abbia bisogno
di comunicare.
Faccio un esempio: voglio creare una nuova fattura:
- form principale: click su toolbar "Aggiungi fattura"
- mostra la form fattura (modale)
- l'utente seleziona "ok"
- il form principale deve aggiornare la lista delle fatture con la nuova
Cosě anche per la modifica, la cancellazione, ecc.
Cosě anche per la modifica, la cancellazione, di un nuovo cliente.
E cosě via.
Se vai avanti, capisci che in fretta il codice _del form principale_ sta
crescendo, e diventa difficile da mantenere...


 :-)
:-D Ehehehhhh.... ROTFL!
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 


 crescendo, e diventa difficile da mantenere...
Io ho fatto un form con tutti i menù e le operazioni principali ed ho creato
l'eseguibile EXE
Poi tutto quello che riguarda le fatture e quindi anche la lista fatture ed
il form per l'inserimento nuova fattura fanno parte di una DLL
Dall'eseguibile non faccio altro che richiamare la dll fattura (lista
fatture) e dopo un inserimento, faccio il refresh del recordset e la lista
mi appare aggiornata.
Spero di essere stato chiaro.
Ciao, Vincenzo

Ciao.
Il tuo caso è abbastanza comune, non per nulla esiste un design pattern
chiamato Observer che serve proprio in questi casi di notifica
etereogenea.
Saluti,
Andrea

 tante DLL, però come fare _architetturalmente_ per farle comunicare?
Oltre al consiglio di Andrea come linea base ti direi di lasciare agli
oggetti d'interfaccia il compito di fare interfaccia.
Tutta la logica "businness" spostala in classi apposite, cercando di
dividere i vari compiti tra le classi in modo chiaro.
Non c'è peggior cosa di vedere classi dai nomi ambigui che fanno di tutto un
po' (male) e con metodi pensati alla bell'e meglio che dopo tre giorni hanno
già 40 parametri di cui nessuno conosce o si ricorda più il significato.
Non sto estremizzando, io in questi giorni sto maneggiando classi con metodi
che hanno fino a 36 parametri, perchè il metodo ogni volta deve fare
"qualcosa in più".
Ciao
--
Qualunque mentecatto può scrivere codice che un computer possa capire.
I buoni programmatori scrivono codice che gli uomini possano capire.
[Martin Fowler]

 Ciao
Ciao,
Andrea

Rispondo qui per tutti e due: grazie mille dei consigli.
Ho cercato (su consiglio di Andrea) Observer design pattern ... ed ho
scoperto delle cose interessanti, che mi possono fare comodo.
Ieri ho cominciato a ristrutturare l'architettura della form main per
prevedere delle classi, ognuna delle quali gestisce "una parte" della
cosa globale. In effetti, sto usando un sacco le propietà, e il codice
del from main è molto più semplice.
Grazie!

 ha scritto nel messaggio
news:i32Id.735277$35.29...@news4.tin.it...

Le proprietà servono se la tua classe risolve un problema specifico.
Quando la classe è un "faso tuto mì" mettere delle proprietà non ha senso
perchè ti trovi la funzione che stampa le fatture insieme a quella che
restituisce il recordset della tabella dei dipendenti.
