Newsgroup: it.comp.lang.visual-basic
Titolo: Mapping tabelle...sono duro a capire

Prima di arrivare a usare ORM e robe varie...meglio capire in piccolo provando a scrivere qualcosa di proprio!
Mi scontro con il mapping delle tabelle del database
Se uso vs2010 e provo a trasportare una tabella.
Me la crea suppergiù come faccio io ma inserisce anche una serie di metodi che non capisco....il fill, l'update..etc etc
Ma scusate...questi non vanno separati dal mapping?
Io ho imbastito una cosa forse troppo arzigogolata allora?
Ho un namespace apposito e dentro una classe per ogni tabella.
Di più c'ho messo solo 2 dictionary....uno chiamato lenCampi che mi riporta la lunghezza dei campi....ed uno TipoCampi che riporta delle info sul tipo e se è o no primary key (mi serve eventualmente per propagare alla gui queste info)
Aggiungi Modifica Cerca etc etc 
io le ho messe a parte
anzi....
io ho una Interfaccia "Ioperazioni"
che dichiara Ioperazioni.AggiungiUtente(strutturaDatiUtente)
la quale tramite un pluginManager guarda che DB ho usato
e traduce AggiungiUtente nella sequenza di operazioni per aggiungere un utente su un file...o su Access...o su mySQL...o su quel che è!
Quindi la domanda....mi sono complicato la vita inutilmente?
Perchè mettono il new, l'update e quant'altro...appresso al mapping????
Leggendo vari articoli (per la verità spesso in Java) sui pattern....mi sembra che sia più aderente alla teoria io...o sbaglio?

 
Te la faccio molto spicciola: studiati il pattern DAO (per il data 
layer) e Busineness Object (per il business layer).
In soldoni: nella parte dati mappi in una classe la tabella 1 a 1 e poi 
aggiungi in un'altra classe i metodi per le operazioni su quella tabella 
(tipo insert, update etc etc).
A questo punto della strada probabilmente non hai ancora un' entità ben 
definita. A livello business costruirai, quindi, la tua entità completa 
che utilizzera internamente la classe che mappa la tabella + quella che 
espone i metodi.
Questa classe di business verrà esposta al lato presentation 
dell'applicazione.
PS: Mi son spiegato da cane, ma se leggi quei pattern ti farai un'idea 
migliore :D

 sembra che sia più aderente alla teoria io...o sbaglio?
dipende da quale modello stai seguendo.
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 Quindi la domanda....mi sono complicato la vita inutilmente?
Una curiosità, ma hai davvero tutta questa necessità di far girare
l'applicazione su qualsiasi DB?
Cioè il cliente ti fa pressioni per usare un Db al posto di un altro?

E' di un comodo totale...ed avendo tempo da dedicarci essendo la fonte di reddito in altri progetti mi interessa approfondire e migliorare!
Cmq si....capita di dover interfacciare il mondo *nix di MySql...o di Postgresql...o di dover interfacciare SQLite....o Access....dipende dalle disponibilità del cliente.
Trovo sempre più spesso gente che ha un pc inutilizzato in un angolo ....una qualsiasi distro ...mysql o postgresql ....e hanno un db centralizzato a costo zero.Però mi capita il piccolo ufficio dove si vuole una app monoutente. O chi ha già comprato SQLserver.
Dopo anni di vb6 e programmi fatti ad hoc e bottiglie di malox assunte....
e stato illuminante fare l'abbonamento a Sky e vedere le peripezie di Gordon Ramsey nelle sue cucine: uno chef bravo non è quello che complica i piatti inutilmente, o che ha un menu complicato. Un ristorante prospera con un menu semplice e buono. Sto cercando di fare lo stesso con i NUOVI programmi: un core sperimentato....e una serie di piccole variazioni per il cliente.
E' finita l'era di reinventare sempre la ruota(il cliente ha una bellissima ruota personalizzata.....ma il costo non ha ritorno economico)!...almeno...per me! 
....capito perchè mi incasino la vita in un sistema che poi si tratta solo di configurarlo per adattarlo al cliente?....sto semplificando il menu!!! :)



Sicuramente troverai vantaggi.
Lo svantaggio principale imho è che non puoi avere delle query ottimizzate 
su un motore del DB, e devi lavorar più di codice. Oddio forse questa è la 
direzione stessa degli ORM.

 direzione stessa degli ORM
un ORM in questo senso ti salva la vita, NHibernate produce delle query 
favolose targettizate proprio a fronte dell'RDBMS con cui sta 
lavorando, è una figata. Lo sto spermentando proprio in questi giorni 
in cui lavoro con Oracle, che per me è tutto un nuovo mondo, e vedo 
dell'SQL completamente diverso da quello che mi aspetterei per SQL 
Server, e documentandomi ho scoperto che quell'SQL è fatto cos proprio 
perchè ottimizzato per Oracle.
è ovvio che non è pensabile ignorare il rapporto che c'è tra 
l'applicazione e il db, ed è per questo che anche quando si usa un ORM 
il profiler deve essere il tuo miglior amico perchè se scrivi delle 
query schifose o senza senso nel "linguaggio" dell'ORM non è che ti 
puoi lamentare se l'applicazione va piano...di certo non è colpa 
dell'ORM :-P


 Cioè il cliente ti fa pressioni per usare un Db al posto di un altro?
Prova a lavorare, tanto per dire, nella pubblica amministrazione, e vedrai quanto è vero.
Ma anche un qualunque cliente che non è "un fila di PC negli uffici" ma ha un minimo di IT, è più contento se può evitare di avere un RDBMS per ogni singolo sofware fetente che deve installare...

Considera che non ho le dimensioni del cliente che può avere ad esempio Nicola.
Cmq a fronte di un
AggiungUtente(listaDati)
ci pensa L'AccessPlugin a trasformarlo in TSQL
o il MySQLPlugin a trasformarlo nel "suo" SQL
e cmq considera che tutti i plugin hanno esposto EseguiSql per invocare anche da alto livello una stored o direttamente un sql (è una contraddizione lo so....ma lo spaghetti code che è in me ha trovato utile in sede di tuning dal cliente ficcare questa spina nel fianco all'applicazione....dovessi fare al volo una alter table....)
Quindi ogni plugin ha dentro di se le sue query!
Me lo ritrovo comodo....assai....a fronte di una complicazione iniziale ...ovvio