Eccoci con la seconda puntata sulle novità sul nostro caro Visual Basic .Net.  In effetti, come ho spiegato nel precedente articolo, con questa nuova versione Microsoft non ha solo migliorato VB6 ma ha riscritto completamente il codice.

Alla base di tutto c’è il .NET Framework che sicuramente merita un approfondimento.

Che cos’è il Framework?

Un Framework è un insieme di classi che collaborano tra di loro e che risolvono o semplificano le problematiche di programmazione. Per esempio, quando visualizzo un form, non faccio altro che ereditare la classe del Framework System.Windows.Forms.Form nella quale è incapsulato tutto il codice che serve per costruire una finestra vuota. Questo vuol dire che il codice che noi non scriviamo, verrà generato automaticamente facendoci risparmiare tempo.

Quindi, alla base di tutto il lavoro c’è l’ereditarietà poichè ogni classe del Framework viene ereditata da Visual Basic .Net (vale lo stesso per C# e C++).

La grande novità è che le classi del Framework sono accessibili da tutti i linguaggi di Visual Studio .Net mettendo a pari dignità Visual Basic con con gli altri linguaggi di sviluppo .Net.

Quindi molte applicazioni o servizi che venivano sviluppate solo in C++ ora possono essere scritte in Visual Basic .Net senza problemi dato che si accede alle stesse classi e il compilato darà lo stesso MsIL (Microsoft Intermediate Language). E’ per questo motivo che una classe scritta in C# può essere ereditata da Vb.net e viceversa.

I Namespace

Nel Framework sono raccolte circa 3500 classi per cui come si fa a trovare quella che ci serve? Il Framework  è suddiviso in Namespace che a loro volta raggruppano classi simili. Ogni Namespace, può contenere altri Namespace creando una vera e propria gerarchia.

Ad esempio, nel Namespace System (che comprende la maggioranza delle classi del Framework), sono compresi:

• System.Data (dove ci sono le varie classi per la connessione e gestione ai   database ADO.Net)

• System.Xml (dove ci sono le varie classi per leggere e scrivere codice Xml)

• System.Windows.Forms (dove ci sono le varie classi relative alla visualizzazione di form sullo schermo)  

Per cui, prendendo come riferimento l’ultimo punto, per visualizzare una finestra, scriverò “System.Windows.Forms.Form.Show()”.

Non sarà comunque necessario scrivere continuamente System perchè .Net provvederà da solo a creare una versione abbreviata di tutte le classi, per cui, riferendomi a System.Data, scriverò solamente Data.

In ogni caso, possiamo creare noi stessi un abbreviazione usando Import. In pratica usando:

Import System.Windows.Forms

per visualizzare una finestra scriverò solamente: Form1.Show()

Le classi

Qualunque operazione voglia fare in .Net, si potrà effettuare tramite un oggetto. Se voglio connettermi ad un database, oppure aprire un file di testo, non farò altro che creare un oggetto che sappia fare questa operazione. Ritornando all’esempio di prima, per visualizzare una finestra userò  

In ogni caso, a noi non interesserà il codice che verrà eseguito dalla classe Show(), l’importante è che si visualizzi sullo schermo una finestra (questo concetto è definito incapsulazione).

L’applicazione in questo modo, non dialogherà mai direttamente con il sistema ma sarà il Framework a farlo per lei.  

Per cui, il concetto finale è che se io devo visualizzare una finestra, non importa se l’utente finale utilizzerà un sistema operativo Mac, Linux o Windows, io effettuerò una chiamata ad una classe e se esisterà un Framework per quel sistema operativo, la finestra si aprirà sempre senza cambiare una riga di codice.

E’ chiaro quindi che Microsoft ha creato un sistema multipiattaforma. L’unica limitazione è che per ora esistono ufficialmente solo due versioni del Framework: una per Windows ed una (Compat Framework) per Pocket Pc.

Ci sono voci non confermate che esiste una versione del Framework anche per ambiente Linux. Questo vuol dire che se io sviluppo un’applicazione in ambiente Windows e installo il Framework .Net su di un sistema Linux, la mia applicazione funzionerà tranquillamente anche su quest’ultimo.

Un altro vantaggio è che le classi sono indipendenti dal linguaggio utilizzato. Per cui se scrivo un’applicazione in Vb.Net, utilizzerò gli stessi oggetti che utilizza C#. E’ per questo motivo che non esiste un linguaggio migliore dell’altro perchè tutti faranno riferimento alle stesse classi del Framework.

Il Linguaggio Intermedio (MsIL)

Ma oltre a tutto questo, esiste un altro punto a favore di .Net: il codice non è più vincolato al microprocessore. Fino a d oggi, i nostri eseguibili (.exe) erano prodotti in istruzioni macchina x86 ossia istruzioni in grado di essere eseguite da microprocessori Intel, Amd e compatibili.

Tuttavia, esistono in commercio in maniera meno diffusa, altri tipi di processore che non potrebbero far girare le applicazioni con istruzioni macchina x86. E’ per questo motivo che Microsoft si è inventata MsIL (Microsoft Intermediate Language).

In effetti, la compilazione di un progetto, realizzato in VB.Net oppure C# (C Sharp), non produrrà  un eseguibile .EXE come eravamo abituati ma un codice Assembly (MsIL sempre con estenzione .EXE) identico per tutti e due i linguaggi di programmazione arricchito da metadati che ne descrivono in modo automatico il contenuto.

Questo linguaggio è un Assembler indipendente da qualsiasi microprocessore e di proprietà Microsoft. Dobbiamo pensare al Framework .Net come un vero e proprio microprocessore software che si interfaccia poi con il microprocessore hardware vero e proprio.

Il tutto funziona in questo modo:

Il Common Language Runtime

Il CLR (Common Language Runtime) è la parte che compila al volo l’applicazione .Net in codice nativo del processore e quindi lo esegue.

Esso si occupa del:

• caricamento ed esecuzione del codice (come appena descritto);

• isolamento dell’applicazione: in modo tale che in caso di malfunzionamento di un applicazione non blocchi gli atri processi di sistema;

• gestione della memoria: si occupa di gestire l’allocazione di memoria, avviare ed eliminare processi e variabili, verificare le dipendenze tra i componenti e coordinare le attività del garbage collector. Quest’ultima fase è particolarmente delicata perché consente l’ottimizzazione e la gestione degli spazi di memoria legati ad oggetti istanziati e dichiaratamente, non piu’ necessari;

• sicurezza: si possono impostare particolari permessi per limitare le azioni o le operazioni di un programma;

• gestione delle eccezioni: quando un applicazione produce un’eccezione che non è stata prevista dal programmatore (ad esempio non trova il file nella directory specificata), al posto di interrompere bruscamente l’esecuzione, il .Net darà la possibilità all’utente di continuare lo stesso;

• interoperabilità: la possibiltà di utilizzare librerie o richiamare applicazioni precedenti (basate su COM)  

Il Common Type System e la Common Language Specification

Uno degli aspetti più evidenti ed importanti di .Net e l’interoperabilità fra linguaggi. Come già descritto, l’intento di Microsoft è che qualsiasi programmatore possa scrivere codice in .Net, con il linguaggio cge già conosce. Perchè questo accada, tutti i linguaggi di programmazione devono essere considerati alla stessa stregua e per ottere ciò, tutto quello che scrivo con un linguaggio deve essere compreso con l’altro.

E’ quì che subentra il CTS (Common Type System) che non è altro che uno standard.

Per esempio, una variabile di tipo stringa in VB6 non poteva essere passata direttamente ad un programma C++, ma doveva essere opportunamente convertita perchè i due linguaggi non memorizzano le stringhe nello stesso modo. Ora tutti i linguaggi che rispettano CTS, utilizzano le stringhe, come i numeri e le date, nello stesso modo, quindi possono scambiarsi direttamente i dati. Inoltre Microsoft ha introdotto e reso pubblico CLS (Common Language Specification), per standardizzare l’adattamento dei linguaggi per renderli compatibili con .Net.

In poche parole, qualsiasi linguaggio supporti questi standard, potrà essese interoperabile con i linguaggi .Net.

Per ora esistono solo VB .Net, C#, C++ tuttavia molte società tra le quali Cobol e Perl stanno realizzando implementazioni.                                                      

Conclusioni

L’ultima cosa ma non per questo la meno importante è che finalmente abbiamo finito di combattere con il REGISTRO DI CONFIGURAZIONE. Si perchè ora per registrare una classe, basta fare un copia ed incolla nella cartella del Framework.

Abbiamo smesso di interagire con quel registro che non finisce mai e pieno di informazioni molte volte inutili che non fanno altro che rallentare il sistema.

Federico Barbati