Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Design ad oggetti di dati in relazione 1:N

Attendo risposte numerose...
Almeno io ci sono ;-)
ciao, hal

 Almeno io ci sono ;-)
Io pure :)
ciao
alfonso

 Io pure :)
Pure io
"quassiasi cosa... a disposizione"
ciao
ugo

 "quassiasi cosa... a disposizione"
Siamo tutti qua... :))
Ciao
alfonso

(tramite classi) di questi dati, come progettereste le classi?
Ok, mi chiamo fuori.
Onestamente, non ho ancora capito se sono troppo stupido per capire
l'utilita' delle classi in queste cose oppure se non mi sono ancora
imbattuto in un problema che veramente ne suggerisse l'utilizzo o se
piu' semplicemente non ho capito il discorso classi :)
Per quanto riguarda il mio programma per il libretti di uso e
manutenzione e i fascicoli tecnici che accompagnano le mie macchine,
alla fine ho lavorato con un po' di query e ho lasciato stare le
classi.
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-VI --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD
   On contrary of popular belief, Unix *IS* user friendly:
    it just appears to be selective who it is friend with

Io pure :)
Io no, ne so troppo poca :)


piu' chi), che ne pensi ?
Io, io :) Sono stato io :)


 Io, io :) Sono stato io :)
ricordavo anch'io lo stesso, ma essendosi fatto avanti alfonso non
volevo smentirlo :)


Ha un senso nel momento in cui la "Lingua" ha valore e visibilità propri,
come già accennavo. Meno se la lingua è esclusivamente funzionale alla
classe Articoli.
Ma in quest'ottica diciamo così "estensiva" dell'analisi iniziale di Roal,
bisognerebba allora considerare le problematiche che si originano da altri
attributi dell'articolo.
P.es. Il prezzo non sarà quasi mai semplice attributo dell'articolo, ma
dovrà essere messo in relazione ai listini, alle condizioni cliente, alle
forme di pagamento, ma soprattutto alle valute: è probabile che se una delle
nostre descrizioni-in-lingua è in russo, il prezzo debba essere espresso in
rubli (o meglio dollari...??? :-)  ) etc...
E chi più ne ha più ne metta...
ciao
ugo


Questo è un altro tipo di discorso.
In fondo mi associo all'idea che non sia necessario "classificare"
(interessante neologismo, nevvero? :-) ) tutto e tutti.
Nel momento in cui si tratta di dati, nel senso di oggetti di business,
l'esperienza insegna come non sia spesso necessario ricorrere a vere e
proprie classi che tendono di frequente a divenire riproduzioni solo in
parte ritoccate delle sottostanti strutture relazionali dei dati.
In certi casi, ciò ha un senso e un'utilità di grande valore, in
particolare:
a) nell'ottica di separazione delle logiche di business dalle sottostanti
strutture dati
b) nell'ottica di "separazione tra gli sviluppatori" delle logiche di
business e delle strutture dati e coloro che dovranno implementare le
ulteriori sovrastrutture elaborative.
In molti altri casi, tuttavia, il "banale" approccio al recordset ottenuto
via Ado o Rdo e Odbc direct o ciò che si preferisce è più che sufficiente
per gestire il livello di complessità tipico delle strutture aziendali.
In fondo, è inutile periodicamente lamentarsi dei rallentamenti introdotti
dalla moltiplicazioone di strati elaborativi (vedi ad es.
MotoreSql-Odbc-Ado), se poi siamo noi stessi a complicare ulteriormente le
cose introducendo uno strato di classe, fatte salve le dovute eccezioni.
E fatta salva anche l'utilità didattica dell'operazione, che può essere di
grande rilevanza; vedi, ad esempio, quell'esame di informatica di cui si
parlava in un thread di qualche tempo fa.
ciao
ugo

 wrote in message
9gllg6$eq1$1...@lacerta.tiscalinet.it...


 "[OT] scusate se mi permetto, ma non si divaga un po' troppo in questo
NG ?"
e' vero e' vero !
eri incazzatissimo per gli ot !
poi, a stare con gli otisti...

16/01/2001 ore 11.38:
Ma guardalo: pur di rubarmi il figliol --prodigo-- si inventa pure un
falso post ;D


 > (lettura, creazione, aggiornamento ed eliminazione) dei prodotti.
Per quanto riguarda l'eliminazione, no prob, poiché l'eliminazione di un
oggetto porterebbe alla distruzione autometica dell'array.
Per quanto riguarda l'aggiornamento, la modifica di qualunque attributo è
molto semplice, poiché la modifica dell'elemento dell'array che ci interessa
è immediata come per la lettura.
Per quanto riguarda la creazione, idem: l'array viene generato in fase di
istanziamento della classe
Se si aggiunge un prodotto, automaticamente l'array viene generato
all'istanziamento del rispettivo oggetto
Per quanto riguarda il db: senza portarsi dietro i recordset, io delegherei
la gestione ad un unica classe con i compiti di generare gli oggetti
Prodotto a partire dal recordset, eliminare un det recordset, ..., e tutte
le altre operazioni sul db che riguardano solo passivamente (=riflessione di
una modifica) la classe Prodotto. Volendo si potrebbe implementare la classe
Prodotto ereditando i medoti di questa classe, chiamiamola "dbEngine", però
visto che verrebbe ereditata solo l'interfaccia e visto che si parla solo di
una classe, io lascerei semplicemente una delegazione piuttosto che
un'implementazione...
Spero di essermi spiegato decentemente...
Ciao,
Moreno

 (combiando "lingua" con "valuta").
certo.
ciao
ugo



chiedo scusa... il messaggio originale? Devo essermi pero diversi post di questo thread... :-((
Ciao,
Moreno
#sirri#@#morenosoft#.com
(togliete "#" dall'indirizzo)
Moreno Sirri VB Site - 
http://www.msvbsite.net
---------------------------------------------------------------------------
Le risposte alle tue domande le trovi sul Sito Comune di questo NewsGroup:
 
http://www.it-lang-vb.net
---------------------------------------------------------------------------


Ah, beh...
E' vecchiiotto a dir la veritą...
Il buon Roal evidentemente era un po' preso e lo ha rilanciato solo ora...
:-)
Vedi su google "Design ad oggetti di dati in relazione 1:N" di Roal, del
16/06/01
ciao
ugo