3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Il .NET Compact Framework
Infine, esiste anche una versione del framework, nota come . NET Compact Framework , pensato per WindowsCE.NET, il sistema operativo scelto da Microsoft per gli handheld devices basati sull'architettura PocketPC 2002.
In estrema sientesi, le applicazioni scritte per questa tecnologia coprono una fascia molto grande di pubblico, sia per quanto riguarda i desktop, quanto per la fascia server che per quella handheld, costituita da PDA, smart phones e tablet PC.
Posizione dominante?
Il fatto che molto presto ci troveremo .NET anche sul nostro cellulare potrebbe essere non visto di buon occhio dai competitor di sempre del colosso di Redmond, e potrebbe per questo portare a qualche conseguenza legale.
Dunque, stiamo alla finestra anche per monitorare eventuali situazioni del genere. Certo è che con un prodotto del genere, Microsoft introduce uno standard quasi de-facto nel campo di servizi e dei prodotti per il mercato consumer in modo particolare?
Perché uno standard?
Semplice: .NET permette di sviluppare qualsiasi tipo di applicazione: stand-alone, client/server, per sistemi handheld (palmari, smart phones, smart devices), per il web.
In pratica, per tutto quello che vuol dire "applicazione su sistema operativo della famiglia Windows".
Come sviluppatore, certamente rappresenta un vantaggio notevole: imparo una volta il Visual Basic.NET, poi lo posso usare per qualsiasi utilizzo, sia la parte client di un progetto, sia quella server, sia l'implementazione per PDA.
Oggi, invece, la prassi vuole che per ognuna di queste singole implementazioni, si utilizzi un linguaggio o una sua variante particolare: non proprio comodo per chi non può permettersi di tralasciare uno degli altri ambienti.
Difatti .NET nasce anche dall'esigenza di poter scrivere un'applicazione e farla girare su tutte le altre piattaforme supportate.
Microsoft ha rubato l'idea a Sun? Per certi versi è vero, .NET è un Java megliorato ed in grande stile. Di Java ha preso le cose migliori, di Java non ha le cose peggiori.
Anche .NET si basa su un CLR (Common Language Runtime), un runtime che esegue al volo il codice, che viene automaticamente convertito dai compilatori in MSIL (Microsoft Intermediate Language).
Dunque, la mia applicazione scritta in VB.NET o in C#, verrà sempre convertita in MSIL prima di essere eseguita.
Il vantaggio di un framework comune per tutti i linguaggi vuol dire essenzialmente una cosa: con .NET utilizzare uno o l'altro è essenzialmente e finalmente una scelta dello sviluppatore .
Tutti i linguaggi permettono di fare praticamente le stesse identiche cose: cambia la forma, la sostanza è la stessa.
Pochi paragrafi fa ho detto che è uno standard de-facto. Come fa ad esserlo se è stato rilasciato da pochi mesi? Semplicemente perché già da due anni, con l'uscita della prima preview beta (luglio 2000), esistono applicazioni scritte per girare con .NET. Il periodo di beta è stato molto lungo ed ha evidenziato gli enormi pregi del framework, con il risultato che oggi .NET è un sistema robusto e già utilizzato da milioni di sviluppatori, anche se in realtà è sul mercato da pochi mesi come versione finale.
Conclusioni
In questa prima parte abbiamo visto una prima introduzione, più teorica, al .NET Framework.
L'argomento è vasto e torneremo sull'argomento la settimana prossima, concludendo il discorso con una introduzione alle altre novità, come C#, ADO.NET ed i Web Services.
C# e VB.NET
La vera grande innovazione del .NET framework è C# (si legge C sharp), un nuovo linguaggio simil C++, che a detta di Microsoft racchiude le cose migliori di Java, escludendone le peggiori.
C# e tutti gli altri linguaggi supportati dal framework, che sono all'incirca una trentina, (da Cobol.NET fino a J#, una versione di Java realizzata da Microsoft), offrono le stesse identiche funzionalità. Questo implica, molto semplicemente, che è finalmente possibile scrivere applicazioni nel linguaggio che si preferisce senza per questo perdere potenza rispetto ad altri linguaggi: un'applicazione VB.NET può fare essenzialmente le stesse identiche cose di un'applicazione Cobol.NET.
La maggior parte dei linguaggi supporati, poi, è utilizzabile per creare applicazioni ASP.NET , oltre che le classiche applicazioni per desktop.
Con il framework sono inclusi inoltre come linguaggi supporati JScript.NET , l'evoluzione delle precedenti versioni di JScript in chiave .NET e VB.NET , in pratica la versione 7 del Visual Basic.
Visual Studio.NET
In principio era Visual Basic, poi venne Visual C++. In seguito, fece la sua comparsa Visual Interdev. Infine, ci fu Visual Studio, il primo tentativo di unificare l'ambiente di sviluppo.
Oggi, con Visual Studio.NET, Microsoft ha riunito in una sola IDE tutto ciò che vuol dire sviluppare applicazioni, di qualsiasi tipo, su sistemi Windows.
All'interno di Visual Studio.NET sono dunque confluite le IDE RAD di VB, VC++ e Visual Interdev. Da una sola interfaccia è ora possibile creare applicazioni Visual Basic.NET, C#, C++, ASP.NET e Web Services.
Il costo non è certamente accessibile a tutti (specie nelle versioni full optional ) però vale certamente tutto il suo costo, visto che permette di aumentare la produttività e di rendere più semplici operazioni complesse.
E' possibile creare applicazioni ASP.NET in un ambiente completamente RAD, in maniera visuale e senza dover (quasi) scrivere nemmeno una riga di codice, con risultati nettamente (e chiaramente) migliori di quanto si potesse fare in passato con tool com Front Page o VID.
IIS 6
Scoperto solo da qualche settimana, con il rilascio delle prime beta pubbliche, Windows .NET Server 2003 ha all'interno un piccolo gioiello: IIS6.
La cosa che mi ha fatto più piacere tra le tante novitò di IIS6 è come gestisce la configurazione e la cache. Partiamo da quest'ultimo punto.
IIS 6 implementa un meccanismo trasparente per lo sviluppatore, che tramite le intestazione della pagina, imposta una cache automatica a livello server. In questo modo, una richiesta non sarà effettuata fisicamente al worker process necessario per l'esecuzione, ma sarà restituita dal processo di IIS 6, più veloce.
L'architettura di IIS 6, infatti, è molto diversa da quella di IIS5: c'è un processo, chiamato httpsys.dll , nella kernel area, che richiama e passa il controllo ai vari worker process, che implementano il supporto per ASP o ASP.NET, che invece sono nella user area. In questo modo un crash del worker process non disturba minimamente il processo principale di IIS, che sta in una area di memoria riservata. Per lo stesso motivo, non ci dovrebbero essere più problemi di buffer overrunning.
In ultimo, ora IIS 6 è configurabile tramite un file XML, sulla falsa riga di quello di ASP.NET: è possibile cambiarlo al volo, spostarlo su altri server, senza dover stoppare o riavviare alcun servizio.
Avremo comunque modo di tornare su IIS 6 nel futuro.
3 pagine in totale: <<Indietro 1 [2] 3 Avanti >>
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
