Microsoft ha reso disponibile per il download Visual J# NET [nuova finestra].
Si tratta di un ambiente di sviluppo rivolto agli sviluppatori Java che vogliano abbracciare lo sviluppo per il .NET Framework. La sintassi di J#, molto vicina a Java, può partecipare a ridurre i tempi di apprendimento del Framework.
Non è comunque possibile realizzare programmi in grado di utilizzare la Java Virtual Machine.
Microsoft ha da poco rilasciato una versione preliminare di ASP.NET Web Matrix.
ASP.NET Web Matrix è uno strumento di sviluppo completamente gratuito rivolto allo sviluppatore che non necessita di tutte le funzionalità comprese nel pacchetto Visual Studio.
Tra le caratteristiche di ASP.NET Web Matrix troviamo:
Le sostanziali differenze rispetto a Visual Studio .NET sono invece:
Non è necessario disporre di Iis, in quanto un piccolo web server è già compreso con Web Matrix.
L’interfaccia grafica ricorda da vicino quella di Visual Studio .NET. Sulla sinistra troviamo l’insieme dei controlli di tipo Html e i Web Server Control che è possibile trascinare all’interno della pagina.
È anche possibile includere i propri controlli o controlli di terze parti. Web Matrix consente di condividere con gli altri sviluppatori il proprio codice, oltre che partecipare a forum e chat.
Anche l’accesso ai database è facilitato. È sufficiente connettersi ad un database e trascinare una tabella per vedere creato un controllo DataGrid già funzionante. È poi possibile intervenire direttamente sulle tabelle e aggiungere nuovi campi.
Alex Homer e Dave Sussman, autori tra l’altro di
Professional ASP.NET 1.0
, hanno realizzato una guida di 70 pagine [nuova finestra] all’uso dell’ambiente, che è possibile
scaricare gratuitamente.
Con l’avvento della piattaforma .NET, Microsoft ha anche rilasciato la nuova versione delle librerie di accesso ai dati, chiamate oggi ADO.NET.
Le caratteristiche di ADO.NET che ne hanno motivato la nascita sono essenzialmente:
Lavorando con ADO.NET e in particolare con l’oggetto DataSet, ci si rende conto di come in ADO.NET si lavora disconnessi dalla sorgente dati:
Questa caratteristica poteva essere esplicitamente richiesta in ADO 2.6, mentre in ADO.NET diventa il comportamento di default.
ADO.NET dispone di un supporto nativo per la gestione e manipolazione di documenti Xml, nonché di sincronizzazione con gli oggetti di tipo DataSet. Passare da una rappresentazione all’altra è quasi trasparente e consente di utilizzare il Data Binding sia quando le sorgenti dati sono database, sia quando stiamo accedendo a documenti Xml.
Come abbiamo visto nella puntata precedente, tra le caratteristiche di ASP.NET che tagliano i ponti con il passato ci sono le tecniche di Data Binding, che consentono di legare un controllo ad una sorgente dati. Negli esempi precedente abbiamo in realtà utilizzato delle sorgenti fittizie, come degli array. La vera potenzialità del Data Binding si ottiene associando i controlli a oggetti ADO.NET.
Per collegarsi ai dati in ADO.NET sono possibili diverse strade.
È possibile utilizzare direttamente un oggetto di tipo Command o un DataReader, ma l’oggetto più completo e complesso è sicuramente il DataSet.
In ADO.NET gli oggetti appartengono a due insiemi:
Nel .NET Framework sono per il momento compresi 2 tipi di Data Provider, quelli per:
Nessuno vi impedisce chiaramente di accedere a SQL Server con il Data Provider di tipo OLE DB; le prestazioni, comunque, non saranno paragonabili a quelle del Data Provider dedicato.
Esiste in realtà un Data Provider per ODBC [nuova finestra], non compreso nel .NET Framework, ma scaricabile dal sito Msdn di Microsoft. Questo provider è utile nel caso sia necessario accedere a sorgenti di tipo non OLE DB, come un database Dbase.
In fase di preparazione c’è inoltre un Data Provider per Oracle [nuova finestra].
Ogni Data Provider è composto da 4 oggetti:
Il DataReader è sicuramente l’oggetto da preferire quando le operazioni sui dati sono visualizzazioni, iterazioni, paginazioni: consente di ottenere le performance maggiori.
Se invece è necessario aggiornare i dati, il DataSet può rappresentare la scelta migliore. Poiché il modello ADO.NET è di tipo disconnesso, il DataAdapter ricopre il ruolo di ponte tra la sorgente dati e il DataSet.
Il DataAdapter si preoccupa così di popolare il DataSet con i dati della sorgente dati e successivamente di aggiornare la sorgente dati con le modifiche eventualmente apportate al DataSet.
Il DataSet è sempre disconnesso dalla sorgente dati e può contenere, a differenza del Recordset ADO, dati provenienti da diverse tabelle e sorgenti dati. Per questo motivo l’oggetto DataSet dispone di un metodo Tables che restituisce una collezione delle tabelle che contiene
Abbiamo appena sfiorato le caratteristiche di ADO.NET, tralasciando tutta la parte relativa al supporto Xml. Lo scopo di questa lezione è in realtà porre l’accento sulle differenze di ADO.NET rispetto ad ADO. Quello che va ricordato è che esistono due tipi di oggetti tra cui scegliere: DataReader, efficiente con dati in sola lettura e forward-only e il DataSet, oggetto completamente disconnesso dalla sorgente dati e comandato da un DataAdapter.
