Newsgroup: it.comp.lang.visual-basic
Titolo: Dubbi su OOP e framework vari: perchè riflettere la struttura di un db in tante classi?

Salve, passate bene le vacanze?
Sarà la mia costruzione mentale da vecchio sviluppatore in asp 3.0
Chiaritemi questo concetto:
perchè dovrei riflettere la mia struttura del db in classi?...dove stà
il vantaggio?(si chiamano orm quei sw/framework che lo fanno vero?)
Mi spiego:
una applicazione generica:
Aggiornamento dati tabella
...ho nell'interfaccia inputato i dati...premo "Salva"
io trovo estremamente comodo: raccogliere i dati dopo la validazione
in una collection e chiamare il metodo "AggiornaTabella" dove gli
passo il nome della tabella ed i dati da aggiornare(o al limite il
nome della stored ed i dati).
Il metodo controlla che db uso...costruisce la query nel dialetto sql
appropriato(o richiama la stored)...esegue e mi restituisce ok oppure
eventuali errori (ad esempio una concorrenza)
Così ho disaccoppiato interfaccia e database...e cambio facilmente
database!
Ma anche faccio manutenzione in maniera facile....se mi cambiano la
struttura della tabella(e purtroppo mi succede nell'arco di tempo
medio di vita di una applicazione)...si traduce in un cambio di query
e in un aggiunta di validazione nell'interfaccia.
Usando una architettura a plugin posso cambiare anche a caldo la
logica di gestione del db.
Scrivo tanto ma mi sembra di godere assai dopo in fase di tuning e
personalizzazione (a differenza di 
http://blogs.ugidotnet.org/topics/archive/2009/02/07/spettacolo.aspx
io mi diverto un po meno perchè i miei clienti partono sempre "bene" e
poi atterrano "male"...imprevisti e cambi di tracciato record si
sprecano! Stimolante si...divertente un po meno!)
Se invece faccio riflettere il db in classi (NHibernate lo fa verò?)
che ottengo? Una più veloce scrittura...ma una rigidità maggiore in
fase di personalizzazione? Se devo togliere il campo Indirizzo2 e
aggiungere il campo Foto (ad esempio)...non faccio prima la modifica
con il mio antiquato sistema?
Illuminatemi
Grazie!

 con il mio antiquato sistema?
Con Hibernate aggiungi una property di Nome Foto alla classe Articoli. E 
basta.
E come tutti i sistemi OOP ottieni che lo sviluppatore lavora verso un 
oggetto, non verso una tabella.
 

 Grazie!
.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

On 24 Ago, 09:13, Mauro Servienti [MVP] <mauroservie...@online.nospam>
wrote:
zac
perchè non dovrei citarti?...a parte qualche frizione iniziale dovuta
al reciproco "assaggio" io rispetto chi ne sà più di me!
Spiego: io sò che il cliente avrà bisogno più o meno di "quei" campi e
anche se non li vuole li prevedo e al limite non li uso.
Però poi trovi il "capocchione" che non gli interessa nulla di gestire
il periodo di rotazione di un prodotto....salvo dopo un anno chiederti
"c'è verso fare una modifica per sapere in 3 mesi quale prodotto è
stato più assortito?" e fino li sono previdente! "Ma vorrei inserire
anche 3 foto di varianti...sempre del solito codice"..."vorrei
inserire il nome della moglie per ricordarmi di fargli gli auguri
attraverso la fattura(non scherzo eh!...ed in ultima analisi essendo
io, oltre che programmatore, anche una puttana commerciale...basta che
paghi...che me frega!"
e qui devo fare appello all'inventore del malox ed alla mia
flessibilità oltrechè alla flessibilità del mio codice!
E:
Ho imparato a gestire un DAL minimale auto codificato per svincolarmi
dal DB ...invoco "AggiornaAnagrafica" e gli passo un dictionary
Nomecampo valore
Ho imparato a usare ancora una interfaccia Winform (XP resiste) e
richiamare metodi generici tipo DisegnaFattura o CreaReport (a dire il
vero lo facevo già in vb6)che poi invocano lo specifico disegno per la
specifica periferica
Ho quasi dominato (non sò se chiamarlo Ioc) la struttura a plugin
tramite reflection per espandere a caldo l'applicazione
....mi hai messo la pulce in testa dei messaggi tra winform...casomai
il giorno che capisco anche come spaccare convenientemente l'app in
vari thread faccio 2+2
Ho fatto una fatica bestia a capire tutta sta roba e sopratutto
metterla insieme che non esplodesse!
Non so se usare un orm al mio punto di conoscenza mi aiuta!IMHO mi fà
solo ulteriore casino! Attualmente una modifica al database si
riflette in aggiungere un campo nel db...aggiungere/togliere un campo
in una winform...aggiungere una riga di validazione
Scrivo (come facevo in vb6) in textbox.tag il nome del campo quindi
non devo modificare nulla nell'update (certo se mi tolgono tag...sono
fottuto)
E' tutto migliorabile...anche se non faccio programmi(ahimè) per
centinaia di terminali o multinazionali...
la remora era buttare via tutto ed usare un orm...non sò se me la
sento....
grazie a tutti per le risposte!

 in una winform...aggiungere una riga di validazione
E se il contesto di gestione dei dati non richiede una interazione utente? 
Ovvero niente Windows Form?
 

 Ovvero niente Windows Form?
ti scrivi un plugin che legge il file (o si interfaccia alla seriale)
e comanda il resto...è ovvio anche se non mi è mai successo che il
display I/O può non esserci
mi è capitato invece l'opposto...e frequentemente....
se hai da fare un pesante data-entry(outsourcing di registrazione riba
per istituto di credito per dirne una)...il cliente NON (ripeto NON)
vuole il mouse ma la cara vecchia interfaccia a caratteri con tutte le
scorciatoie del caso (a luglio l'ultimo caso)...anche a costo di
imparare a fare il pianista!
Li pagano un tanto a registrazione...(un lavoro di merda...sopratutto
per il povero operatore)

 grazie a tutti per le risposte!
.m


 display I/O può non esserci
Secondo me non hai capito, ma fa niente.
 

 sviluppo software quando si parla di transazione di business (aka Unit
...ed infatti mi sforzo di capire ma non mi riesce.
Sarò "minimale" ...o solo vecchio.....
Interfaccia Grafica
....controlli....regole di input(ereditate o file o altro)
Logica...prende i dati già controllati e validati...li elabora
(tipicamente somme sottrazioni percentuali)
Li passa ad un modulo classe servizio (dipende dal sw) che li riflette
sul db (il codicillo decide volta volta se usare stored o sql)
Ovvio che ho un sistema che propaga dal db all'interfaccia il tipo di
validazione (non accetta numeri se si aspetta lettere...non prende un
campo letterale per una data)
Io mi sforzo di tenere il meno possibile i dati sul client e
rimbalzarli il più presto possibile sul server...mentre mi pare di
capire che l'approccio che tenti (bontà tua) di spiegarmi va nel verso
opposto (ed allora forse capisco i grafi e quant'altro)
...per dire...una riga di fattura la rimbalzo subito sul db e
riaggiorno la griglia o evidenzio l'errore o risolvo la concorrenza...
cerco di tenere le cose più semplici possibile perchè tanto sarà il
ragioniere contabile prossimo alla pensione ad incasinarmele(quello
che ha windows xp con il tema nero su bianco perchè "ci vede
meglio!")...o la segretaria "bona" del boss! (e non dico altro)
Cmq...mi metto a studiare sta roba...ehm un link di approccio non
terrorizzante?

 (tipicamente somme sottrazioni percentuali)
Ahia, controllati e validati? E chi lo dice? No no, il controllo e la 
validazione DEVE farli la logica. O perlomeno NON fidarsi della 
presentazione. Altrimenti che logica è?
 

zac
... Altrimenti che logica è?
WodkaLogic....
:)

 terrorizzante?
http://www.codeproject.com/KB/database/Nhibernate_Made_Simple.aspx
http://devlicio.us/blogs/alan_northam/archive/tags/NHibernate/default.aspx
http://wiki.fluentnhibernate.org/Getting_started
http://www.hookedonlinq.com/LINQToNHibernate.ashx
poi cercati informazioni sui concetti di:
- Identity Map;
- Unit of Work;
- Domain Model;
- Object Model;


On 24 Ago, 22:30, Mauro Servienti [MVP] <mauroservie...@online.nospam>
wrote:
...
Thanks!

 - l'indirizzo che ha creato non esista, idem come sopra;
Forse hai un concetto di transazione un poco troppo allargata :-)
 

Ciao gdg,

ovvio è di business :-) con la transazione a cui siamo abituati, quella 
sul db, condivide solo il nome :-P


 sul db, condivide solo il nome :-P
Anche come transazione business mi pare un po troppo "allargata".
Io la modifica alla Partita IVA la lascerei, cosi come l'indirizzo di 
spedizione, dato che non sono attributi esclusivi della
"transazione" abortita.
Ma è solo una mia fisima :-)
Ora però ti faccio una domanda trabocchetto: la partita IVA e l'indirizzo di 
spezione nella transazione (fattura, bolla, fissato bollato etc) li persisti 
nella registrazione della transazione? :-)
 

 nella registrazione della transazione? :-)
tecnicamente si perchè c'è il rischio che altrimenti la risultatnte 
fattura non sia buona perchè l'indirizzo non è mai arrivato dove 
doveva.


 fattura non sia buona perchè l'indirizzo non è mai arrivato dove doveva.
Vedo che non cadi nel tipico errore dello  "scienziato dei missili" :-)
 

Ciao,

Aggiungo un paio di considerazioni alla discussione.
I Database fanno molta fatica a scalare orizzontalmente principalmente 
per una questione di costi, una configurazione attivo-attivo sia con 
Sql Server che con Oracle ha un costo in licenze che fa paura... si 
parla di centinaia di migliaia di €... quisquiglie insomma :-/
Quando si parla di scalabilità è doveroso valutare dove si vuole andare 
perchè è facile scoprire che non ci serve avere scalabilità orizzontale 
ma è abbastanza portare il serverino ad avere 8 core e 16gb di RAM per 
vedere schizzare le prestazione dcell'applicazione e una macchinetta 
del genere ve la da Dell con poche migliaia di eurozzi che sono 
sicuramente meno dell'investimento tecnologico per avere qualcosa che 
scala veramente (e non solo sulla carta) in maniera orizzontale.
Inciso a parte sta di fatto che il database rischia di diventare 
rapidamente il collo di bottiglia dell'applicazione, al crescere dei 
client (ne bastano poche decine) con la massa di informazioni che 
pretendiamo trattare oggi giorno un'architettra basata su 2 tier (okkio 
che i tier non sono layer) non paga più.
Per 2 tier intendo che tra client (che gira sul pc dell'utente e 
database (che gira sul server) non c'è nulla. In uno scenario come 
questo se voglio cominciare a scalare seriamente devo per forza mettere 
qualcosa tra i 2 e quindi come minimo passare a una struttura a 3 tier 
che metta tra il db e il client un set di servizi che possono stare su 
macchine (okkio al plurale) diverse e se tutto è fatto bene mi 
permettono di scalare orizzontalente unico modo sensato per scalare 
all'infinito.
In un modello come questo è palese che per il client il database non 
esiste più e quindi non ha nessun senso che ne abbia nozione, ergo 
tutto deve essere astratto in un modello (o più modelli) che permetta 
di far comunicare i vari mondi senza che si sia tecnologicamente legati 
a qualcosa di prettamente implementativo come la marca e il modello di 
database che si è scelto o peggio ancora al flavour di ansi-sql che ci 
sta portando dietro... sia esso T-Sql o PL-Sql poco importa.
