Chi intende realizzare applicazioni per la piattaforma di Microsoft dovrà abituarsi a utilizzare nuovi metodi di programmazione, che stanno per essere resi disponibili nella suite Visual Studio .Net. Ecco una rassegna dei principali componenti coinvolti nella trasformazione.
Con la piattaforma .Net, Microsoft intende spostare l’ottica dalle applicazioni ai servizi Web. Tutto è pensato e costruito seguendo tale direzione, con il preciso scopo di creare un punto di riferimento unico per aziende, utenti consumer e sviluppatori di applicazioni-soluzioni. Brevemente, .Net agisce nell’ottica del computing distribuito, offrendo un framework per realizzare servizi basati sul Clr (Common language runtime). La struttura intende offrire tutti i vantaggi di un modello di programmazione a oggetti: le chiamate a oggetti remoti sono realizzate attraverso un protocollo di tipo Dcom, mediante il Serialization binary formatter, o Soap, attraverso il Serialization Soap formatter.
Spazio ai programmatori
.Net è stato progettato per raggiungere il maggior numero di utenti possibile; a tale scopo è stato necessario dotarlo di strumenti che consentissero compatibilità sia a livello struttura che a livello di dati, oltre alla possibilità di un’ampia scelta di linguaggi di programmazione. Per offrire queste opportunità, il codice scritto non viene tradotto direttamente in linguaggio macchina dal compilatore, ma viene archiviato in memoria come moduli binari in Msil (Microsoft intermediate language). Solamente nel momento del lancio dell’applicazione i moduli sono tradotti in linguaggio macchina da un compilatore veloce Jit (Just in time).
L’introduzione di un livello intermedio consente di creare applicazioni per .Net con qualsiasi linguaggio di programmazione che possieda un compilatore per l’Intermediate language e che sia in grado di supportare il set Cls (Common language system), un set di tipi di dati la cui comprensione è indispensabile per effettuare il cross-language. Ogni linguaggio con cui è possibile creare applicazioni per .Net, inoltre, può interagire con il type system di ogni altro modulo .Net compilato nel sistema. È possibile, per esempio, derivare senza alcun pre-trattamento una classe di dati da un’altra che è stata utilizzata in un linguaggio diverso, perché il framework è in grado di garantire il supporto dei diversi tipi di informazione, siano essi classi o strutture.
Linguaggi di classe unica
Realisticamente, non tutti i linguaggi saranno in grado di supportare l’intera gamma dei servizi Clr e tutti i tipi utilizzabili e riconosciuti all’interno di .Net, anche se, almeno inizialmente, non dovrebbero esistere linguaggi di prima e seconda classe. La risoluzione delle possibili incompatibilità si basa sull’idea di utilizzare strumenti di conversione automatica, che rendano trasparente il processo di importazione. I tipi di dati utilizzati all’interno di .Net costituiscono un superset di Cls chiamato Cts (Common type system); all’interno di .Net, tutti i tipi sono totalmente autodescriventi e non richiedono la registrazione di metadati. Per estinguere alla radice il problema dell’incompatibilità, sono state, tuttavia, studiate nuove versioni dei linguaggi, ottimizzate per l’utilizzo con la nuova architettura Microsoft, che sono disponibili nella suite Visual Studio .Net. Le modifiche apportate a Visual Basic, per esempio, hanno portato alla creazione di Vb.Net, che offre un pieno supporto dei costrutti .Net ed è quindi destinato a sostituire Vb Script e Visual Basic in un futuro prossimo.
Anche C++ è stato esteso per supportare le configurazioni avanzate di Clr: l’amministrazione della memoria mediante il garbage collector (gestore della memoria ereditato dalla Jvm), la compatibilità di tipi binari e gli attributi dei client richiedono parole chiave non standard, aggiunte proprio in questa versione, chiamata Managed C++. Attraverso un comando di linea, /com+, il compilatore è in grado di trattare un file C++ come Managed C++: in questo modo, esso viene archiviato in memoria in Intermediate language. Managed C++ permette di utilizzare le funzionalità del Clr sia sull’intero programma sia su singole porzioni di codice: in questo caso, il resto del codice viene trattato in modo "unmanaged". Questa soluzione può portare a uno stile di programmazione definibile "poco elegante", ma consente di ottenere vantaggi soprattutto in progetti che non possono beneficiare di un funzionamento completo sotto la piattaforma .Net.
Il ruolo del "vecchio" Com
L’infrastruttura di .Net non è costruita su Com; tuttavia, tra le co-classi Com e .Net esistono compatibilità e interoperatività bidirezionale, grazie all’utilizzo del meccanismo Com Intercop.
Le basi dei modelli Com+ e .Net sono costruite sui medesimi principi di programmazione fondamentali: comprendono l’uso di dati di tipo dinamico, il remoting trasparente, la compatibilità dinamica e la separazione dell’interfaccia dall’implementazione. Il Runtime collable wrapper permette di accedere alle co-classi Com dal runtime di .Net: l’accesso dei tipi .Net attraverso la linea di comunicazione Com avviene grazie a un Com callable wrapper. Entrambi i componenti sono installati dal Clr in modo nascosto, e lavorano nello stesso modo ma in direzione opposta. Uno consente alla co-classe Com di funzionare regolarmente come oggetto .Net, convertendo l’interfaccia esposta dal componente Com in interfaccia compatibile con .Net. Il Com callable wrapper, invece, esplica esattamente l’azione opposta: converte interfacce pubbliche di classe .Net in interfacce compatibili Com. Per realizzare la conversione, la classe .Net deve essere pubblicata nel registro di sistema, in modo che il Com service manager possa localizzare il wrapper Com, che a sua volta richiama l’oggetto .Net. Il registro di sistema è realizzato mediante il tool di comando Regasm: questo, in fase di input, richiede il file name di un assembly, nuovo termine che indica una lista di file che agisce come una singola unità, perché i file stessi condividono proprietà in diverse aree, tra cui sicurezza e punti di accesso.
Un esempio pratico: per accedere da .Net a una libreria di tipi Com è sufficiente usare il comando di linea Tlbimp, in caso di interfaccia compatibile con Automation. In questa specifica situazione, viene generato automaticamente il Runtime callable wrapper: una libreria pre-compilata di tipi invia una Dll, a cui in seguito il modulo .Net del client fa riferimento. Nel caso in cui l’interfaccia Com non sia di tipo Automation compatibile, è necessario, invece, procedere a una mappatura manuale del codice.
La piena compatibilità di C#
C#, invece, è stato creato da Microsoft appositamente per la scrittura del codice .Net: partendo da elementi di Java e di C++, la società ha cercato di scrivere un linguaggio orientato a oggetti, che fosse particolarmente intuitivo e leggibile. Il suo processo di standardizzazione è da tempo iniziato, con la presentazione, presso i comitati tecnici Ecma, di alcune "regole grammaticali" contenenti specifiche Clr di C#. La ricerca della massima compatibilità ha portato, tuttavia, a una penalizzazione delle prestazioni, che si nota soprattutto al momento della prima esecuzione dell’applicazione. Esiste, comunque, la possibilità di tradurre in anticipo il codice da Msil in linguaggio macchina. La precisione nella gestione della cache e l’amministrazione della memoria offerta dal garbage collector, che lavora a livello del sistema, dovrebbero ridurre in buona parte l’impatto della macchina virtuale in termini di utilizzo di risorse. Le performance delle applicazioni .Net dovrebbero risultare, così, in linea con quelle del codice non amministrato. Secondo fonti Microsoft, nel peggiore dei casi le prestazioni sono inferiori di circa il 10%, non tenendo però conto dei tempi per effettuare la compilazione Jit. Oltre al linguaggio C#, le tecnologie ausiliarie più importanti correlate al framework sono basate su Asp (Active server pages), su Ado (Active data object) e, infine, su Winforms.
Asp+ per programmare il Web
Il rinnovamento delle Active server pages ha portato all’implementazione di Asp+, completamente integrato nel Clr: questo permette al programmatore di scrivere pagine dinamiche "server side" utilizzando i linguaggi compatibili con .Net, anche se contengono altri tipi script.
Le pagine Asp+ sono caricate immediatamente prima dell’esecuzione: la cache viene gestita in modo da limitare l’impatto dei tempi di caricamento.
Per migliorare le prestazioni, sono stati estesi anche il modello a oggetti, in modo da avere file di configurazione basati sul Xml, e un supporto per il debugging, mentre si è introdotta una più efficiente gestione delle interazioni con l’utente remoto e la modularizzazione delle routine Asp nelle librerie. Il framework .Net utilizza Ado+ come interfaccia per l’accesso ai dati object oriented: il modello di programmazione di Ado+ è, sostanzialmente, simile a quello di Ado, anche se più flessibile. Per continuare a utilizzare la tecnologia Ado nelle applicazioni .Net, è sufficiente importare la libreria dei tipi Ado: è possibile accedere alle sue co-classi mediante il meccanismo di Com Intercop.
Winforms contiene, invece, interfaccia, classi e tipi di dati specifici per interfacce di utenti grafici: è pensato sia per applicazioni Ui classiche di tipo standalone, (per cui il programmatore può beneficiare di Api avanzate orientato a oggetti, di un sofisticato modello per la gestione degli eventi e di uno strumento con un’ampia compatibilità di linguaggio), sia per sistemi a più livelli distribuiti multitier.
