Dato che ho una cliente che mi ha chiesto un gestionale semplicissimo
(Anagrafica clienti e gestione di un paio di tabelle)..ho pensato che ᅵ
la volta buona per aprire .net e iniziare.
Ad occhio lo trovo ESTREMAMENTE piu bello e meno spartano dl vb6,
leggendo qua e lᅵ nel tentativo di capire i vari cambiamenti,
tra l'altro, ho scoperto che ( a meno di non usare OCX di terzi ),
a progetto finito basta distribuire la cartella BIN insieme al Framework
aggiornato e come per magia, tutti i problemi di setup di VB6
relativamente a dll e ocx non registrati spariscono al 100%.
*ᅵ vero?*
Altra cosa:
La gestione della grafica del programma, la gestione del resize e
dell'anchor degli oggetti, la gestione degli oggetti picture, la
creazione dell'oggetto LINKLabel :) Tutto nativo e (quasi) automatico.
L'impressione a caldo ᅵ : sono felice come un Muflone allegro ;)
*sbaglio?* ;)
la navigazione del database direttamente dall'ambiente di programmazione:
Finalmente non devo ALT-TABBARE tra vb6 e msaccess quando non mi ricordo
i nomi di tabelle e colonne!
E poi ci sono centinaia di altre cose come i costrutti Try/catch che mi
spilluzzicano parecchio...
Insomma... evviva .net!!
[Si prega la gentile utenza di sviluppare questo thread, rispondendo
a questa parte di post, per darmi modo di chiarirmi ancora un pᅵ le idee
su qualunque argomento riguardante .net]
:----------------------------------------------------
Passiamo alle cose tristi.
Il collegamennto a un database access, l'esecuzione di query (select *
from anagrafica) e la restituzione dei dati in una listview.
Non vi sto chiedendo pezzi di codice.
Vi sto chiedendo di parlarmene, di discutere un pᅵ a proposito della
logica di programmazione, di cosa ᅵ cambiato tra vb6 e [.net]
tecnicamente, di come si fa e perchᅵ.
insomma: il discorso ᅵ:
Se mi rispondete lasciandomi un pezzo di codice, io copio, incollo ,
modifico e faccio funzionare.
Se invece ne discutiamo, mi date l'opportunitᅵ di capire bene la logica
e i tecnicismi del nuovo linguaggio in modo che
alla prossima gestione anagrafica non debba tornare qui a elemosinare
codice sorgente! :)
[Resta inteso che , chiaramente, ho fatto ricerche su Google e spulciato
un pᅵ di forum: ma le notizie scarseggiano, gli esempi non sono
chiari...soprattutto la gente si ifogna con i Datagrid che io odio dal
profondo.
... e comunque siamo lontani anni luce da un newsgroup in cui, se mi
viene in mente di fare una domanda, ho un filo diretto con chi ci
capisce piu di me]
Beh, non mi sembra male come Thread per uno che ᅵ sparito di qui da
anni, no? :)
>
> Ad occhio lo trovo ESTREMAMENTE piu bello e meno spartano dl vb6,
> leggendo qua e lᅵ nel tentativo di capire i vari cambiamenti,
> tra l'altro, ho scoperto che ( a meno di non usare OCX di terzi ),
> a progetto finito basta distribuire la cartella BIN insieme al Framework
> aggiornato e come per magia, tutti i problemi di setup di VB6
> relativamente a dll e ocx non registrati spariscono al 100%.
>
> *ᅵ vero?*
Ni. per progetti molto grossi ᅵ comunque consigliabile utilizzare un
pacchetto di installazione.
>
> Altra cosa:
> La gestione della grafica del programma, la gestione del resize e
> dell'anchor degli oggetti, la gestione degli oggetti picture, la
> creazione dell'oggetto LINKLabel :) Tutto nativo e (quasi) automatico.
> L'impressione a caldo ᅵ : sono felice come un Muflone allegro ;)
>
> *sbaglio?* ;)
Diciamo che molte cose sono facilitate. :)
> Passiamo alle cose tristi.
>
> Il collegamennto a un database access, l'esecuzione di query (select *
> from anagrafica) e la restituzione dei dati in una listview.
DataTable e DataAdapter.
Tradotto in soldoni, non mi cazzino i puristi, il DataTable ᅵ una
tabella contenente i dati (quello che in VB6 era piᅵ o meno il Recordset).
Il DataAdapter invece ᅵ uno strato che consente al DataTable di
comunicare con la tabella fisica.
Cerca guide su questi due oggetti. Poi dopo passi alle raffinatezza 8se
ne hai necessitᅵ ovviamente).
>
> Beh, non mi sembra male come Thread per uno che ᅵ sparito di qui da
> anni, no? :)
eh no :)
Nicola
>
>
>
Essenzialmente:
I vantaggi non sono nella quantità di codice che scrivi ma nella sua
chiarezza e riusabilità!
L'ambiente dominato ti permette di fare applicazioni n-Tier con tutto
quello che ne consegue! E chi lo fà come mestiere principale sà che
questo approccio alla lunga ripaga commercialmente!
Lo svantaggio sono il buttare via tutta la sovrastruttura e la voglia
di studiare che deve essere continua!
ADO.net?
non è più solo quello!
Linq....Linq to Entities...ed altro a venire!
Approccio corretto il tuo?
Per me no!
Perchè l'ho fatto anche io ed ho "cannato" miseramente! (ma tu
sicuramente sei più bravo di me)
Non si comincia ad usare dotNet "perchè si deve fare un programma"!
Vuoi male al tuo cliente? Ti paga male? Non lo vuoi rivedere più?
Si comincia da piccoli esempi...in progetti didattici anche alla cazzo
di cane (la solita videoteca per esempio)...provando adonet..poi
salendo di complessità...poco per volta...assimilando i concetti!
Altrimenti ti ritrovi con uno spaghetti code senza ne capo ne coda!
Come si fa a dirti che dotNet ti permetterebbe di farti un tuo
provider "custom" da derivare dalla classe base.
E che potresti usare quello per la tua applicazione.
E che il tuo provider custom potrebbe essere "localizzato"...ora per
MSaccess...ora per Oracle...ora per Postgresql...ora per Sql Server?
Come fare a dirtelo ed a "proportelo" se non hai super-assimilato come
gestire le classi in dotNet...e la sintassi del vb.net?
Non per scoraggiarti....ma partire SUBITO con un programma commerciale
mi sà tanto di carro qualche chilometro avanti ai buoi!
Con Amicizia
W40°
Oddio, immediato non direi.
Io faccio largo uso di DataReader , soprattutto per le prestazioni che
ha. Perᅵ io macino alcune decine di milioni di record in poche ore.
Ma per un gestionalino, inutile complicarsi la vita, soprattutto se ᅵ il
primo programma.
Diciamo che DataTable e DataAdapter possono bastare per iniziare. ;)
Nicola
Nicola, come mai non li vedo nell'elenco degli oggetti di .net ?
trovo Dataset, e datagridview...
ma nᅵ datatable, nᅵ dataadapter.. :(
Ehm, chiedo scusa per l'errore da niubbo. :)
Prima ho chiesto, POI ho cercato ;)
Risposta:
http://www.startvbdotnet.com/ado/datatable.aspx ;)
e sembra anche eccessivamente customizzabile.. :)
EHM.....
non per ar il bastian contrario....
e te credo che il datareader abbia buone prestazioni: si ciuccia una
connessione e se la monopolizza per tutta la durata della query!
Se con pochissimi utenti lo puoi fare perchè hai molti (milioni) di
record e cerchi la prestazione pura senza ottimizzazioni...come
dire...con un po più di utenti....è un ottimo stress test delle tua
lan!...oltrechè un ciuccia risorse formidabile!
In buona sostanza...tanti record e un datareader....è la cosa più
simile a lavorare connessi con il vecchio VB6
Non lo dico solo io eh.....lo dice M$ e tutti gli MVP!
IMHO (ma non solo io)
milioni di records? falli elaborare dal db server...la notte!
datareader?
con pochi record e solo se necessario!
http://msmvps.com/blogs/WilliamRyan/archive/2005/02/26/37015.aspx
> IMHO (ma non solo io)
> milioni di records? falli elaborare dal db server...la notte!
> datareader?
> con pochi record e solo se necessario!
Beh, noi qui abbiamo creato un motore ETL simile a DTS-SSIS ma scritto
completamente da noi in .NET
In 40 KB abbiamo tutte le funzioni degli SSIS a noi necessarie,
possibilit� di scrivere script in .NET compilati al volo,
MultiThreading, ProviderFactory per avere le massime prestazioni su ogni
DB, ecc... il tutto completamente nostro, modificabile\aggiornabile a
nostro piacimento senza dover star dietro ai capricci di MS tali per cui
su molti clienti siamo stati forzati a rifare tutto il vecchio lavoro
(scritto con i DTS, non pi� compatibili con SQL Server 2008).
Gira tutto sull'application server, solitamente di notte, perch� sono
procedure lanciate in batch su macchine a *minimo* 4 processori e 8 GB
di RAM (anche se ci sono banche dove per poche migliaia di record basta
un dual-cpu e 2 GB di RAM) dove il tempo di elaborazione di ogni
procedura pu� andare dai 30 minuti fino alle 4-5 ore in base al numero
di record e alla complessit� delle elaborazioni.
In queste condizioni il DataReader � esattamente quello che fa per noi.
Nicola
> In queste condizioni il DataReader è esattamente quello che fa per noi.
>
> Nicola
eh eh eh ....ma sei un ex-democristiano???
Il succo è che alla fine hai dato ragione a me....anche se pareva
esattamente l'opposto!
....diavolo di un centrista!!!
:)
LOL... dare del democristiano a me sarebbe come dare della vergine a
Cicciolina! :-PPPP
Si, infatti ti davo ragione, ma spiegavo anche il perch� della scelta.
Ciao bello!
Nicola