Newsgroup: it.comp.lang.visual-basic
Titolo: ADO.NET - INFERNO O PARADISO?

Salve a tutti...
Programma da oltre 10 anni e in particolare gli ultimi anni della mia
vita li ho dedicati al Visual Basic 6.0.
Ho scritto km di codice utilizzando visual basic e Ado... Ora mi sto
avvicinando al nuovo sistema Visual Basic 2008 e 
ADO.NET
.
VB 2008 lo reputo un linguaggio veramente interessante... Diciamo che
ci voleva proprio...
Ma ADO.NET.... Sara' che lo devo ancora studiare bene...  o e'
semplicemente un caos?
Ho l'impressione che in ADO si scrivevano molte meno righe di codice
per ottenere procedure stabili ed efficienti... Creazioni dei
database, transazioni, recordset disconnessi, recordset virtuali,
cursori LockBatchOptimistic ecc. 2 Righe et voila....
Perche' l'hanno incasinato in questo modo?
E' giusto astrarre in questo modo il database complicando notevolmente
la scrittura e la lettura del codice?
Scusatemi ma e' solo uno sfogo personale... forse dato dalla mia
insesperienza in visual basic 2008....
Ciao a tutti...
PS... Speriamo che venga presto domattina che mi arriva il libro
Programmare 
ADO.NET
 2.0 di David Sceppa... cosi' forse ho le idee piu'
chiare...

 chiare...
Siccome ho voglia di scrivere:
A torto o a ragione...dipende dalla visione delle cose....i potenti "dei del 
computer" hanno deciso che il mondo vada verso i servizi...e abbandoni 
progressivamente le soluzione stand alone.
In futuro avrai SO scaricati da internet...programmi affittati a minuti etc 
etc
Uscendo da M$...basta vedere le politiche di Apple...o di Google....
Bene...stante questa visione del mondo...come implementarla?
Con 2 assunti:
1) L'utente è sempre SEMPRE connesso ad internet tramite banda larga
2) L'utente non deve per forza essere un esperto
se implementi queste cose....non ha più senso parlare di "server 
connesso"....cursore dinamico...recordset....locking pessimistico...
perchè?
perchè farlo rallenterebbe in maniera pesante la rete su cui passano i 
servizi!
Ecco allora la scelta...SEI SEMPRE DISCONNESSO....e quindi niente recordset!
Lock dei dati?...solo OTTIMISTICO (il vecchio batchUpdate)
Logica disconnessa cosa comporta in associazione con la facilità d'uso?
Il fatto che l'interfaccia SIA SVINCOLATA COMPLETAMENTE dallo strato 
business e dallo storage dei dati!
Come conviene implementare tutto ciò?...incapsulando tutto in oggetti!
Ed allora come diventa un tipico percorso
Utente: Interfaccia grafica (carina o orribile quanto vuoi)--> richiesta 
dati...elaborazione della richiesta (validazione...non vorrai chiedere un 
numero dove si aspetta un testo vero?)...richiesta effettiva allo storage 
dati (che può essere un DB...ma anche un file XML...o una zona di 
memoria...o un sito internet)...elaborazione...risposta...INVIO DATI al 
client..elaborazione dati...mostra dati su interfaccia
Questo è a grandi linee il giro dei dati...chiedi dei dati e te li 
inviano...poi con quelli memorizzati temporaneamente in locale....ci fai 
quello che vuoi!
Ecco perchè si sono inventati il dataset...un contenitore dove dentro metti 
oggetti di vario tipo...che provengono da dove vuoi...ANCHE da un 
database...ma non solo!
Se usi gli strumenti visual dell'IDE...il dataset ti viene fuori 
tipizzato....ogni record è descritto da una classe che istanzia una 
collezione di oggetti (non è proprio vero...ma pensarla così aiuta a 
capire!)
Quindi scorrere una tabella NON ESISTE con movenext
ma con For each...è una collezione di oggetti!
Non solo....
sei costretto a pianificare....se hai una tabella di 1 milione di 
records....non puoi più linkarla direttamente come qualche disgraziato 
faceva con il vecchio ADO....perchè la tabella di 1 milione di records 
verrebbe temporaneamente parcheggiata nel tuo harddisk...devi andare di 
query filtrate...o lavorare di stored e comunque farti inviare pochi 
dati!...altrimenti mandi in tilt la tua lan!!!
E per finire la chicca
Se USI vs2008...e cominci da zero....ADO.net ti è utile come INFARINATURA e 
cultura di base...MA IL vero oggetto da studiare è LINQ e l'entity 
framework.
Il futuro è lì.
Cosa fanno sti cosi???
detto in 2 parole...ti svincolano COMPLETAMENTE dal database...tu hai a che 
fare con classi che rispecchiano un database...o un servizio web ...o un 
file o altro ancora...
voglio aggiungere un record?...istanzio una nuova classe e me ne frego 
dell'sql o di qualche altro linguaggio che sta sotto e che mi aggiorna 
effettivamente il database!
Non devo perdermi in mille tabelle o stored o query...mi concentro sullla 
logica dell'applicazione e poi fa tutto lui!
E' tutto fatto per dare un minimo di comodità al programmatore...in un mondo 
dove lo storage cambia in continuazione...e non è raro che lo storage sia un 
servizio web!
Ciauz!
p.s.
Io linq lo sto digerendo piano piano...e ancora ne ho di cose da capire 
anche di ado.net....però indubbiamente...è comodo...parecchio comodo!
Sopratutto se fai programmi multiutente
-----------------------------
Mio Blog
http://www.martek.it/dblog/default.asp
Mia città
http://wodka40hall.myminicity.com/
***
Best Shit of 2008: DOOMSDAY!
http://www.martek.it/dblog/articolo.asp?articolo=120
 

 Sopratutto se fai programmi multiutente
Certo che ne hai fatta di strada in pochi giorni. Fino a qualche giorno
fa i tuoi messaggi avevano questo tono: :D
http://tinyurl.com/5zoo73
Nicola

 Non solo....
Il movenext esiste attraverso un altro oggetto che è il bindingSource, che 
ti aggancia un controllo sulla tua form (ad esempio una textbox) con un 
insieme di dati complesso.
Però è corretto il tuo ragionamento. Non esiste più il concetto di record 
corrente, hai tutti i record a disposizione in cache.
Eventualmente il movenext serve solo per cambiare la visualizzazione dei 
vari record a disposizione sulla form.
Il problema vero del disconnesso è la gestione della concorrenza, ma questa 
è un'altra storia
Umbe 

 Nicola
Che ti devo dire....
Solo i cretini non cambiano mai idea!
Studiando di più...mi son reso conto che SE il mondo va in quella 
direzione....mi conviene usare NET ( e l'ultima scopertaLINQ mi piace 
assai!...mi han sempre tormentato le "paccate" di query sparate al server!)
-- 



IMHO č senza dubbio un buon libro almeno per capire il nuovo 
ADO.NET
.
Dopo che l'ho letto e ho cominciato ad usare i vari dataset, datatable 
ecc... ho visto che in determinate applicazioni conviene proprio abbandonare 
tutto a favore di classi tipizzate e collection...decisamente piů 
performanti! Se frequenti o frequenterai anche il NG di 
ASP.NET
 troverai 
molti personaggi ostili a tutto c'ho che un dataset! ;-)
Ciao, Vincenzo

 assai!...mi han sempre tormentato le "paccate" di query sparate al server!)
Ottimo! Sono felice per te. Restando a VB6 ti saresti perso un sacco di
belle soddisfazioni (e devo dire che con .NET ne sto avendo tante).
Mi lascia un pò perplesso solo la parte di gestione di WPF nell'IDE di
VS 2008, ad esempio:
-perchè mi hanno cambiato di nuovo il nome delle proprietà? In Vb6 per
la label c'era la caption, poi diventata Text ed ora Content... non
possono decidere una c@##o di proprietà e lasciare quella sine die?!?)
-Perchè nell'IDE le proprietà sono raggruppate per aree tematiche e non
posso metterle in ordine alfabetico?
-Come si toglie quella bruttissima area di ricerca per le proprietà?
-Come si disabilita l'antialiasing (es finestra propretà dei controlli)
visto che tutto il sistema (e lo stesso visual studio che prende le
impostazioni dal sistema) ha l'antialiasing disabilitato?

 impostazioni dal sistema) ha l'antialiasing disabilitato?
Perché anche le applicazioni WPF stesse usano un antialiasing tutto 
loro, indipendentemente da quello del sistema operativo (e parecchio 
peggiore). Questa è un'altra cosa sicuramente da rivedere per il futuro.
Io ho notato che sul portatile con Vista si presenta in modo 
accettabile, ma sul desktop con XP è inguardabile.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Saluti, VITRIOL

 cosa, non solo testo.
OK, sono stato un po' sintetico e non si capisce, ma io sono niubbo 
cronico e sono perdonato ;-P
La proprietà Content eredita da ContentControl, e accetta un Object. La 
semplice proprietà Text di una Label WinForm accetta invece solo una 
stringa.
Volendo, ad esempio, io posso assegnare una immagine alla proprietà Content.
In XAML:
         <Label Margin="65,75,51,110" Name="Label1">
             <Label.Content>
                 <Image Source="D:\Temp\Prova.png"/>
             </Label.Content>
         </Label>
Da codice:
         Dim img As New Image
         img.Source = New BitmapImage(New Uri("D:\Temp\Prova.png"))
         Label1.Content = img


 è migliorato un po' con l'SP1.
http://blogs.zdnet.com/microsoft/?p=1595
What's next for Microsoft's Visual Studio
ciao, a.