Newsgroup: it.comp.lang.visual-basic
Titolo: Guru dell'OOP aiuto!...dubbi e chiarimenti sulla logica di un programma

Proseguo nel mio viaggio interiore nel capire con una soluzione fatta
da me i vari strati di una applicazione.
Sono a questo
DBreale <--->plugin gestione SQL DBreale <--->Classe manager con
interfaccia generica gestione base dati <---> classe business <--->
Interfaccia utente
Sembrerà strano...a me sembra strano...(abituato ad un mondo di
personalizzazioni ed eccezioni del cliente che mi portava a scrivere
montagne di codice)...ma tutto FUNZIONA!
per dire invoco dbmanager.AggiungiCliente(nuovocliente as Cliente)
e mi va a finire nella tabella di Access....cambio una
impostazione...e va a finire in una tabella MySQL....mitico...come ho
fatto a non farlo prima!
Solo che ora devo renderla robusta.....con i dati di test stra-
controllati il giro funziona!
Ma con i dati reali?
Mi spiego
io ho riflesso la tabella Clienti...in una classe ClientE...con tante
proprietà quanti sono i campi.
MA   esempio:
problema!
Campo nome accetta 40 caratteri al massimo.
non avendo fatto ingeneria informatica mi trovo nei casini....dove
sposto questo controllo???
Leggendo in quà e in là io avrei capito questo
le entità (si chiamano così le classi che mappano tabelle vero?) vanno
lasciate "pure"...in quanto la validazione dell'input è roba da GUI.
Quindi farsi carico di inserire non più di 40 caratteri è problema
dell'intefaccia.
...se è vero.....
come propago in maniera efficiente la dimensione di un campo nella
catena di relazioni fra moduli?
dallo strato DBreale all'interfaccia che sono esattamente agli
antipodi?
Mi vengono in mente mille opzioni che però mi senbra violino tutti i
concetti a cui ho aderito fino ad ora:
...dal file di testo al file xml
...ad una classe apposita che segue la classe che mappa la tabella
...ad una serie di proprietà in più nel mapping tabella....
quale sarebbe la soluzione didattica?
e quale la più efficiente?(se non coincidono)
Grazie!

 da me i vari strati di una applicazione.
ad integrazione ...aggiungo....per chi come me non avesse capito
perchè non posso cablare direttamente nell'interfaccia un controllo
sui 40 caratteri massimi della textbox nomecliente.
voglio propagare per il semplice motivo che la lunghezza max dei
caratteri deve essere dinamica
Se per un cliente deve essere 30...cambio solo la struttura tabella
del dbreale...e automaticamente l'interfaccia sà di accettare solo 30
caratteri! mi basta questo...non cambierò mai tipo di dato...riscrivo
la parte del mapping per quello!

La classe che effettua la persistenza nel DB deve comunque adattare i dati 
affinchè possano essere persistiti senza generare eccezioni non gestite.
Quindi la tua business logic dovrebbe esser informata dei vincoli propri di 
ogni attributo e propagare questa informazione alla UI che può decidere di 
gestire come vuole la presentazione e la validazione all'utente finale 
sempre tenendo conto che comunque chi avrà l'ultima parola è sempre la 
classe di persistenza.
Saluti.

 Saluti.
se vabbe...tradotto?
...l'ho detto in altri termini ma l'ho detto anche io!
La domanda era....che cosa usare per propagare la info dal db
all'interfaccia?
un file (binario o xml)
una serie di property
una pergamena
una classe ausiliaria
un attributo....una lapide in marmo....
io ho le mie idee ma vorrei non influenzare la risposta...ed evitarmi
brutte figure

se vabbe...tradotto?
Tolta la pergamena, la lapide di marmo ed il file (in parte) in realtà 
rimangono tre cose cose che poi sono una.
Fa tè.

Secondo me non è la GUI che deve conoscere la lunghezza del dato ma 
casomai la GUI ne deve essere a conoscenza tramite la struttura 
sottostante. Sempre imho visto che hai fatto tante prop quanti sono i 
campi, devi fare delle analoghe prop che ti ritornano la lunghezza del 
campo in base al nome ad esempio (hashtable o altre forme di mappatura).
Esempio
GetFieldLeght(Byval field as string ) as Integer.
Per sapere effettivamente la lunghezza dei campi le strade sono due.
O tramite metodi override la cambi di volta in volta ad ogni 
aggiornamento software in base alla nuovs dimensione del campo, oppure 
ti apri la tabella con uno dei tanti strumenti e ti vai a leggere le 
caratteristiche del campo incriminato (ad esempio all'avvio della App 
sprechi quei 5-10 secondi per scandagliare le tabelle e leggere le 
dimensioni dei campi).

 Interfaccia utente
cut alla wodka! :)
Ahhhhhhhhhhhh!!!!!
I nuovi mostri!!!  :)
-- 
Greg 

 wrote:
<zac>
alla mi sono fatto un ulteriore esame della mia "logica".
Se rendo tutto flessibile imho rende tutto non solo complicato...ma
INUTILMENTE complicato
Dovrei avere una routine che scannerizza la struttura tabella e mi
valorizza un dictionary LunghezzaCampi...e poi un altro per le primary
key probabilmente
E questo dovrebbe scattare tutte le volte che usi quelle classi a meno
di non rendere persistente per tutta l'applicazione la classe (es.
Cliente)... credo però ciò vìoli la corretta impostazione oop del
progetto.
Mi sono detto allora:
Qualunque DB io usi....la struttura della tabella cliente
difficilmente varierà. E se varierà sarà solo in conseguenza di una
personalizzazione.
Allora tanto vale cablare dentro l'entità cliente un dictionary che
riflette le lunghezze dei campi. Valorizzato al new della classe
direttamente.
Quando varierò la struttura ...dovrò ricordarmi di aggiungere/togliere
property ED ANCHE variare la lunghezza dei campi nel new.
Bon!...mi sembra la cosa più chiara ed indolore!
Mi sarebbe anche venuto in mente di riflettere in un file la struttura
dei campi per eventualmente settare l'interfaccia indipendentemente
dall'uso delle classi db manager...ma mi sembra tropppo: esiste un
caso in cui io uso l'interfaccia valorizzandola  e non la rifletto nel
database?....probabilmente si...ma ora non mi sovviene!
Che seghe mentali di Lunedì mattina!!!!!!
Saluti

scusa l'ironia ma che razza di database "mutante" devi gestire.
Hai i campi che cambiano lunghezza da un momento all'atro senza preavviso?


 Hai i campi che cambiano lunghezza da un momento all'atro senza preavviso?
zac
Non ho il "databeast" mutante...lo sono i clienti!!!
Talvolta credo che provengano direttamente dalle lande desolate di
Fallout!

 INUTILMENTE complicato
Noi abbiamo un applicativo *totalmente* flessibile, perchè ogni cliente
ha esigenze diverse e nessun cliente ha campi uguali a quelli di altri
clienti (facciamo, in gran parte, ETL su ambienti bancari)
Come gestiamo la cosa?
Ci creiamo un dizionario in cui abbiamo tutti i campi che dobbiamo gestire.
Man mano che creiamo tabelle aggiungiamo eventuali campi al dizionario.
Ogni campo ha una serie di proprietà (lunghezza, descrizione, natura,
ecc...).
In questo modo possiamo girare su qualsiasi DBMS, non abbiamo necessità
di fare scansioni delle tabelle sul db e, cosa molto utile, se cambiamo
una proprietà di un campo, questo si propaga su tutte le tabelle in
automatico.
Infine, gli utenti spesso hanno bisogno di maschere di data entry. No
problem, creo graficamente una maschera (più o meno come fa Access) ed
ho già tutte le proprietà dei singoli campi nella tabella dizionario.
Nicola

 quale sarebbe la soluzione didattica?
la validazione è tipicamente di due tipi:
- necessaria per garantire l'integrità dei dati;
- necessaria per garantire la logica di business;
Un esempio per capirci:
entità "Indirizzo" con un attributo "CAP" il cap è obbligatorio? non è 
detto ;-) se però c'è ha delle regole ben definite (integrità del dato) 
se quell'indirizzo è usato per la spedizione di un oggetto in un 
negozio di ecommerce allora il cap diventa obbligatorio mentre fincheè 
come utente non cerchi di spedire nulla il CAP non è obbligatorio.
In entrambi i casi a mio modo di vedere la validazione va fatta ogni 
qualvolta sia possibile. Sul db è ovvio che resta solo quella per 
garantire l'integrità.
Io di solito faccio validazione da codice, ma un sistema vale l'altro, 
quindi un sistema a plugin che carichi le regole da un file xml è una 
soluzione plausibile.
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 - necessaria per garantire la logica di business;
grazie!