2 pagine in totale: <<Indietro 1 [2]
Web User Controls
Tra gli oggetti definibili in maniera rapida dallo sviluppatore ci sono gli user control, controlli programmabili scritti in uno dei linguaggi supportati dal framework.
Possono essere sia compilati, sia semplici: ci penserà il motore ASP.NET a compilarli nel caso in cui sia necessario, il tutto in maniera trasparente all'utente.
Nel primo caso vanno inseriti nella directory /bin/ , nel secondo hanno l'estensione .ascx, comoda perchè di default ASP.NET blocca sia l'esecuzione, sia la visualizzazione di questo tipo di file, mantenendoli dunque sicuri da accessi via web di tipo fraudolento.
Gli user controls sono comodissimi, ad esempio, per creare dei pezzi di codice che implementano particolari funzionalità, senza riscrivere tutto da zero: form di ricerca, form di login, funzioni di amministrazione.
Non è nemmeno tanto remoto il caso in cui un sito sia formato da una sola pagina, che in base a determinate informazioni si occupa di visualizzare un controllo anzichè un altro, semplicemente variando un parametro.
Per chi ha sviluppato la propria applicazione ASP suddividendo la visualizzazione delle parti ricorrenti in più include, questa operazione di traduzione in user controls potrebbe rivelarsi più rapida che in caso contrario, anche se in tutti i casi si tratta solamente di variare alcuni parti di codice (togliere un include ed inserire il riferimento allo user control) più che di stravolgere tutto.
ADO.NET ed il databinding
La più grossa novità dopo l'OO di ASP.NET è certamente l'uso intensivo del databinging. E' possibile "mappare" il contenuto delle fonti dati (database, file XML e collezioni di qualsiasi tipo più in generale) su molti degli oggetti disponibili.
Questo vuol dire abbandonare per sempre il concetto di recordset e di ciclo sullo stesso per visualizzare i dati che contiene: ora basta utilizzare un controllo repeater o un datagrid per avere a disposizione funzioni molto più potenti e complete.
Addio al recordset, dunque: ora l'accesso ai database è effettuato tramite un oggetto dataReader, che in pratica si connette al database, legge le informazioni contenute, le inserisce al proprio interno e termina la connessione.
Con i recordset invece la connessione è sempre aperta fino a che non si è finito di lavorare sullo stesso.
Questo cambiamento di rotta permette di avere applicazioni più veloci, che occupano il database solo per il tempo strettamente necessario a fare una copia dei dati in esso contenuti.
Ammetto che anche io all'inizio sono rimasto un po' spaesato per questo nuovo modo di lavorare, abituato da oltre cinque anni ad utilizzare MoveNext per passare alla riga successiva. Dopo un po' di abitudine però, è quasi impossibile tornare indietro, perchè la potenza di un datagrid e la sua versatilità non sono nemmeno lontamente paragonabili a quello che si può si fare con un recordset.
Se poi si pensa che con il databinding creare dei template per i risultati della query è davvero semplice e che una maschera stile Excel per modificare i dati di un intero database richiede una trentina di linee di codice, allora questa sensazione si fa più che mai netta ed i vantaggi superano lungamente le prime (normali) difficoltà a passare ad un modo completamente nuovo di scrivere codice.
C'è dell'altro
Con VB.NET non si utilizza più Set o Let per dichiarare un riferimento ad un oggetto. E' sufficiente dichiarare l'oggetto stesso con Dim.
A proposito di Dim, VB.NET a differenza di VBS, utilizzato nelle pagine ASP, necessita della dichiarazione delle variabili. Potete omettere il tipo ed in questo caso VB.NET ne creerà una di tipo Object, effetuandone la conversione (casting) nel tipo appropriato attraverso l'early binding, in fase di compilazione.
I tipi supportati da VB.NET sono all'incirca gli stessi supportati da VB 6. Stesso discorso per C#, con qualche piccola differenza.
Infine, ricordate che le variabili Session ed Application di ASP.NET non sono visibili da ASP e viceversa.
Conclusioni
Se pensate di aspettare che venga rilasciato qualche tool per la conversione automatica, siete fuori strada: il concetto che sta alla base delle due tecnologie è talmente differente che di fatto è impossibile che venga creato un tool di questo tipo davvero affidabile.
Migrare da ASP ad ASP.NET non è facilissimo e richiede un po' di tempo, specie all'inizio quando la dimestichezza con il nuovo modo di intendere la pagina di ASP.NET non ci è ancora ben chiaro.
I benefici di una conversione sono evidenti in tutti quei casi in cui l'accesso ad un database è frequente e per certi versi pesante: i nuovi oggetti offerti da ADO.NET in questo caso danno il meglio di sè, specie se utilizzati con la nuova gestione della cache a livello di server, che permette di mantenere in memoria, già eseguita, una pagina, servendola a tutte le richieste successive.
2 pagine in totale: <<Indietro 1 [2]
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
