Gli speaker di FWC 2005 La location di FWC 2005 L'agenda tecnica di FWC 2005 Iscriviti alla FWC 2005 Come arrivare a L'Aquila e alla FWC Dove dormire a L'Aquila Contatta FWC Gli sponsor FWC 2005
Torna all'HOME page di FWC 2005
Tecnologie

ASP.NET 2.0
ASP.NET 2.0 si presenterà con alcune novità interessanti.
Il cuore del prodotto rimarrà più o meno immutato rispetto all’attuale versione 1.1, ma ci saranno nuovi HttpHandler, nuovi HttpModules, una nuova gerarchia di classe Page che utilizza le Partial Class di Whidbey e non ultimi nuove caratteristiche di gestione dei Web Form.
Particolarmente interessante è la possibilità di definire Master Page che contengono il layout e gli elementi comuni alle varie pagine o sezioni di una applicazione. È anche possibile definire Theme e Skin riutilizzabili dalle varie pagine. Le Web Part sono integrate con nuovi controlli. Cross-Post e ValidationGroup forniscono più modularità alle pagine.
Tutta l’area conosciuta con il termine Data Binding è stata rivista per dare la possibilità allo sviluppatore di utilizzare controlli, denominati DataSource Control, e scrivere meno codice possibile per le operazioni comuni di accesso ai dati.
Un’altra novità degna di nota è rappresentata dal meccanismo con cui i controlli producono il loro output. Tutti i controlli ASP.NET Whidbey infatti adattano il loro output in base al device da cui proviene la richiesta Http. Questo consente di utilizzare gli stessi controlli (e le stesse conoscenze) per fornire contenuti a Desktop, Pocket Pc e dispositivi WAP.
Membership, Role Manager e Personalization sono i tre grandi building block su cui poggia il nuovo prodotto. Questi tre nuovi building block consentono una gestione semplificata, ma comunque completamente personalizzabile, di utenti, gruppi, ruoli e relativa profilazione dell’utente. Membership si incarica di gestire le informazioni di login dell’utente per la Forms Authentication. Deve essere visto come una semplificazione nel codice da scrivere in ASP.NET 1.x per autenticare gli utenti. Role Manager invece è un componente completamente nuovo e gestisce i vari ruoli applicativi, sia dal punto di vista amministrativo che durante il runtime. È un nuovo componente, non esiste niente di simile in ASP.NET 1.x. Personalization invece si incarica di gestire il profilo dell’utente. Si basa per default su uno schema preconfigurato per memorizzare le informazioni su un database (Access o SQL Server), ma ovviamente consente di appoggiare queste informazioni su supporti differenti. In realtà tutti e tre i componenti citati si basano su un’architettura aperta (a personalizzazioni di ogni tipo) denominata Data Provider.
Vedremo anche come personalizzare questi tre personaggi implementando le interfacce necessarie.

.NET Compact Framework 2.0 e Sql Mobile 2005
La prossima versione del .NET Compact Framework introduce nuove funzionalità sotto forma di classi supportate e migliora le performance in molte aree funzionali già presenti nella versione attuale.
Per quanto riguarda le caratteristiche generali citiamo la possibilità di fare Unload di Application Domain, la possibilità di usare Friend Assembly in C#, la migliorata gestione dei thread con BeginInvoke e EndInvoke per chiamate asincrone.
System.Xml supporta XmlSerializer per la serializzazione delle classi, ricerche Xpath su documenti XML e l’utilizzo di XSD (XML Schema Definition) associati a documenti XML, con conseguente possibilità di validazione.
Finalmente il DataSet espone il metodo GetChanges, ben noto agli sviluppatori desktop, per creare un nuovo DataSet con le sole modifiche effuttuate alle tabelle contenute in esso. Questo consente di inviare solo i dati modificati verso Web Service che provvederanno all’aggiornamento effettivo del database riducendo notevolmente il carico sulla rete. Oggi tale metodo non esiste, anche se è possibile riscrivere il suo funzionamento: a tale scopo si veda l’articolo http://blogs.devleap.com/rob/archive/2004/11/10/2003.aspx.
Per quanto riguarda la sicurezza, il nuovo framework supporta NTLM , IPV6, certificati X.509 e le classi per la crittografia.
Un’altra caratteristica, attesa soprattutto da chi ha iniziato lo sviluppo per Windows CE in eMbedded C++ o eMbedded Visual Basic, è la possibilità di invocare oggetti COM. COM Interop consente, per esempio, di lavorare con le API esposte da Pocket Outlook (Pocket Outlook Object Model: POOM) e altri oggetti nativi. Le chiamate possono essere effettuate in early-binding o late-binding (IDispatch). Inoltre è possibile seguire il marshaling di tipi grazie all’implementazione di nuovi metodi della classe Marshal, compresi i tipi OLE Authomation. Si può usare l’ormai famoso Tlbimp.exe (Type Library Import Tool) oppure il classico Add Reference da Visual Studio .NET 2003 per generare lo “strato di interoperabilità” necessario. Non è comunque supportato il Single-Threaded Apartment Model.
Come nella tradizione .NET è possibile agire sui file di configurazione dell’applicazione (applicazione.exe.config) per forzare le applicazioni scritte per la versione 1.0 a girare con il runtime del framework versione 2.0 senza dover ricompilare il tutto. Anche se ovviamente l’applicazione non sfrutta le nuove funzionalità offerte, si può avvantaggiare delle maggiori performance offerte dalla nuova versione.
Le prestazioni sono notevolmente migliorate (anche nell’attuale versione beta) nella JIT-Compilation, nell’accesso ai dati su SQL Server for Windows CE, nella chiamata a web service e nella gestione della memoria tramite il Garbage Collector.
Il nuovo framework consente di compilare e fare debug delle applicazioni senza utilizzare Visual Studio .NET e senza impazzire. L’SDK del Compact Framework .NET 2.0 è incluso nell’SDK della versione del Framework .NET 2.0.

Sql Mobile 2005
Oggi esiste già una versione ridotta (notevolmente ridotta) di SQL Server per l'ambiente Windows CE. L'obiettivo è avere una struttura dati identica a SQL Server sui dispositivi Pocket PC (o comunque basati su Windows CE) e un motore di accesso ai dati utilizzabile nativamente con ADO o ADO.NET (con la stessa filosofia del desktop), oppure replicando i dati via Http dal database centralizzato.
A partire dalla prossima versione del database server di Microsoft, nome in codice Yukon, nome reale SQL Server 2005, verrà alla luce un nuovo mini-SQL Server denominato in codice "Laguna", nome reale SQL Server Mobile Edition versione 3.0. Rappresenta la prossima versione di SQL Server for Windows CE.
Come ogni nuova versione, le nuove caratteristiche sembrano veramente interessanti, soprattutto dopo aver lavorato per oltre 4 anni con le versioni precedenti.
Finalmente si possono creare i file .sdf (le strutture di SQLCE) anche dall'ambiente desktop, si possono eseguire Query dal desktop sia sui database SQLCE residenti sul desktop stesso che sul device.
Il nuovo motore consente di visualizzare il Query Plan (Execution Plan) e utilizzare i "query hints" per ottimizzare la normale esecuzione delle query sul device.
Un'altra novità è rappresentata dai DTS (Data Transformation Services), che saranno nativi nella prossima versione.
Il SqlCeResultSet è derivato dal SQLResultSet e consente di avere cursori aggiornabili e navigabili, oltre che eseguire operazioni di data binding sul device.
Sarà possibile avere accessi concorrenti al database: nella versione attuale è consentita una sola connessione ai file .sdf e quindi sarà possibile sincronizzare i dati durante l'utilizzo dell'applicazione.
Tutta la fase di sincronizzazione dei dati con il database centralizzato espone servizi di notifica per conoscere lo stato di avanzamento delle operazioni e magari fornire all'utente status bar e indicatori di progressione. Nella versione attuale non è possibile conoscere lo stato di avanzamento della sincronizzazione e avvertire l'utente in nessun modo (anche solo segnalando che il device sta sincronizzando e non si è bloccato totalmente).
La sincronizzazione dei dati avviene ancora via Http e le due tecniche sono rimaste pressoché identiche. La sincronizzazione via Remote Data Access consente di sincronizzare le modifiche effettuate ai singoli campi senza dover passare l'intero record. L'operazione di Pull su un set di dati campione di un'applicazione "normale" risultà più veloce di oltre il 30%. Per quanto riguarda la Merge Replication sarà possibile avere Subscription multiple.
L'ultima novità ? Finalmente sarà installabile anche su SmartPhone e ...udite udite...sul Tablet PC. SQL Server Mobile Edition diventa quindi il database per tutti i dispositivi mobili per offrire Remote Data Access verso un database server centralizzato. L'obiettivo NON è comunque quello di rimpiazzare per le applicazioni desktop SQL Server 2005 Express.

SQL Server 2005 e .NET
In 3 anni abbiamo avuto modo di conoscere e apprezzare il Framework .NET da vari punti di vista: codice managed, garbage collector, code access security, interoperabilità fra linguaggi ecc. SQL Server 2005 si presenterà “integrato” con .NET: cerchiamo di capire cosa vuol dire e cosa implica questa affermazione.
Dalla versione 7, SQL Server non è più un’applicazione monolitica, bensì, il motore di storage è separato dal motore relazionale. Il motore di storage contiene i componenti per gestire le transazioni, i lock, le pagine di dati, gli indici, mentre il motore relazionale fornisce componenti per l’esecuzione delle query, delle Xquery, i vari ottimizzatori, la gestione della memoria e del codice SQL. Nelle versioni precedenti di SQL Server potevamo optare per due metodologie di scrittura di codice che gira “sul database”: T-SQL e extended stored procedure. T-SQL è l’implementazione proprietaria Microsoft di SQL-PSM definito nello standard SQL. Il codice T-SQL è integrato nel database e utilizza tipi di dato (data type) con la stessa rappresentazione del motore di storage. Il passaggio dei dati fra T-SQL e il motore di storage avviene senza conversioni o marshaling il che rende il codice efficiente nell’utilizzo dei data type come il codice compilato che gira nel motore di storage. Il codice T-SQL viene però interpretato da SQL Server, il che lo rende meno efficiente del codice compilato nel motore di storage, anche se tipicamente questo non influisce sulle prestazioni del codice che esegue operazioni sui dati. Influisce però sulle performance del codice che esegue calcoli o operazioni sulle stringhe. Nelle versioni precedenti alla 7, SQL server precompilava tale codice in tre diversi formati per ridurre il problema citato, ma dalla versione 7 in poi questa ottimizzazione non viene più effettuata.
La seconda modalità di scrittura del codice è rappresentata dalle extended stored procedure, codice scritto in un linguaggio compilato, come il C++ ad esempio, che può quindi eseguire calcoli numerici o manipolazione di stringhe in modo molto più efficiente rispetto al codice T-SQL. Inoltre una extended stored procedure può accedere a risorse del sistema operativo non disponibili in T-SQL (file, timer, accesso a internet ecc). Il rovescio della medaglia è rappresentato dal fatto che tale codice risulta meno efficiente sulle operazioni di accesso ai dati in quanto l’utilizzo di OBDC o OLE-DB richiede una conversione dei tipi e una connessione verso il database; le connessioni, come sappiamo, sono risorse costose. Il codice T-SQL invece non richiede conversioni e connessioni verso il DB. Inoltre, il codice delle extended stored procedure non può essere “controllato” da SQL Server e quindi potrebbe eseguire operazioni che consumano risorse sul sistema o utilizzare la memoria destinata a SQL Server o addirittura eseguirne uno shut down.
In SQL Server 2005, il codice T-SQL gira in modo pressochè identico rispetto alle versioni precedenti e quindi rappresenta sempre un’ottima scelta per l’accesso ai dati. Per i milioni di programmatori SQL, questa sarà ancora la modalità preferita per il codice di lettura e manipolazione dei dati.
Nella versione 2005 sarà però possibile scrivere stored procedure, function e trigger anche in un qualunque linguaggio .NET, il che consente di usare per i flussi operativi all’interno del db lo stesso linguaggio con cui scriviamo le applicazioni. Tale codice girà in un Application Domain completamente isolato dallo stesso SQL Server e quindi può disporre di risorse diverse rispetto a quelle utilizzate dal database stesso. Il codice .NET ha gli stessi benefici dal punto di vista di compilazione rispetto alle attuali extended stored procedure in quanto viene compilato “just-in-time”; è possibile però utilizzare tecniche object-oriented per modellare le classi da utilizzare e il motore di esecuzione può gestire l’allocazione della memoria e prevenire eventuali accessi “illeciti” alle aree di memoria.
Viene anche fornito un Data Provider .NET per ottimizzare l’accesso ai dati dal codice managed: nel codice che lo utilizza è possibile utilizzare tipi di dato .NET o tipi di dato SQL; alcuni tipi di dato .NET come Sytem.Int32 non richiedono conversioni, mentre altri come System.Decimal devono essere convertiti prima di essere utilizzati. Per evitare queste conversioni e marshaling le classi, i tipi di dato SQL, inclusi nella System.Data.SqlTypes corrispondono ai tipi di dato SQL nativi.
Inoltre, il provider ADO.NET interno denominato System.Data.SqlServer contiene alcune classi per ottimizzare l’esecuzione del codice: per esempio, la classe SqlExecutionContext consente al codice .NET interno di condividere connection e contesto transazionale con il codice .NET dell’applicazione chiamante.

Avalon e XAML
In principio pensato per Longhorn (Windows 2006) il nuovo ambiente grafico denominato Avalon si appoggia a un nuovo linguaggio dichiarativo di definizione dell’interfaccia utente denominato XAML. In realtà Avalon sarà disponibile anche per Windows XP e Windows 2003: vale quindi la pena di dare un po’ di spazio all’interno della giornata a questo nuovo ambiente.
In Avalon abbiamo due possibilità per definire il modello applicativo. La prima è scrivere una serie di righe di codice in un linguaggio di programmazione (C# per esempio), utilizzando classi diverse ma la stessa filosofia e metodologia .NET. Il secondo metodo, ereditato dal web, consente di descrivere l’interfaccia utente utilizzando un nuovo linguaggio di markup chiamato XAML (Extensibile Application Markup Language). Tale linguaggio è un dialetto XML che utilizza elementi definiti in uno schema (schemas.microsoft.com/2003/xaml) e consente di descrivere il layout in maniera dichiarativa. I file XAML possono anche anche essere compilati per produrre un eseguibile a tutti gli effetti. Il processo di compilazione si effettua con un tool chiamato MSBuild che riceve in pasto un file di definizione del progetto applicativo e che descrive le varie componenti dell’applicazione stessa.
Obiettivo di questa sessione è fornire una panoramica sulla sintassi di XAML, mostrarne le potenzialità per capire le possibilità delle nuove interfacce del futuro.


Contatta FWC