Vi anticipo le slide per il webcast architetturale di domani alle ore 11.00 per la durata minima di un'ora e trenta minuti circa

Di cosa parlero' durante il webcast di domani:
- Applicazioni distribuite
- Architetetture basate su servizi
- Componenti utilizzate per applicazioni e servizi
- Criteri di progettazione per le componenti
Cosa non vedremo domani rimandando a degli articoli che preparero' e pubblichero' nei prossimi giorni sul nostro sito http://www.dotnet2themax.it:
- Sicurezza, comunicazione, policy di tipo operazionali di gestione
- Architetture di deployment

A domani, vi aspetto  :)
Giuseppe

Qualche settimana fa scrivevo un post a proposito della covarianza e controvarianza dei delegate in C# 2.0, stupendomi del fatto che in giro per la rete in tanti parlano di queste nuove feature ma senza spiegare a cosa possono servire realmente.

Poichè tutti gli eventi .NET sono gestiti mediante delegate, grazie alla controvarianza è possibile che un unico metodo possa gestire più eventi del tipo (sender, e). anche se la loro signature è leggermente differente. Supponiamo di avere questo metodo:

   Sub GestoreEvento(ByVal sender As Object, ByVal e As EventArgs) 
      ..   
   End Sub

Un metodo di questo tipo è in grado di gestire tutti gli eventi del tipo (sender, e), anche se il secondo argomento non è un EventArgs ma un tipo che eredita da EventArgs. Quindi un metodo di questo tipo è in grado di gestire virtualmente tutti gli eventi definiti nel .NET Framework, con pochissime eccezioni. (L'evento AppDomain.AssemblyResolve è una di queste eccezioni, perchè non è un metodo Sub ma una Function che restituisce un oggetto Assembly.)

Anche se la controvarianza permette in teoria di far gestire tutti gli eventi di un oggetto da un unico metodo, nella pratica le cose sono un po' più complicate, perchè il metodo GestoreEvento ha modo di sapere quale oggetto sta scatenando l'evento (tramite l'argomento sender) ma non quale evento è stato scatenato. Per ottenere questa informazione occorre scrivere del codice un po' più complesso.

Insomma, alla fine ho scritto un componente EventInterceptor che potete sistemare sulla superficie di un Windows Forms e che vi permette di catturare tutti (o alcuni) eventi di un controllo sul form (o al limite di tutti i controlli sul form) per mezzo di un unico gestore. Trovate l'articolo e il codice sorgente a corredo a questo link.

Com'è noto, Visual Studio 2005 include un designer per creare automaticamente una classe My.Settings, che contiene le impostazioni sia a livello di applicazione che di utente. Anche se il designer è decisamente comodo, non è chiaro perchè usare un designer debba essere più semplice che scrivere una classe che esponga quelle impostazioni sotto forma di campi e proprietà, che le carichi automaticamente da disco e che, se modificate, le salvi automaticamente al momento di chiudere l'applicazione. Dal mio punto di vista, l'approccio scelto da Microsoft per VS2005 è la (solita?) esasperazione del concetto RAD, solo che in questo caso le operazioni necessarie per definire la classe My.Settings non fanno in realtà risparmiare tempo rispetto alla definizione via codice delle stesse entità.

Queste considerazioni mi sono venute spontanee non ragionando in astratto, ma mentre scrivevo le mie prime applicazioni.NET 2.0. Avevo necessità di un meccanismo per salvare tutte le impostazioni del programma in un file, un po' come quando in Visual Studio salviamo tutte le impostazioni di un progetto in un file .sln. A pensarci bene, il problema è simile (o meglio, identico) al problema di salvare le impostazioni relative all'utente e alla applicazione: si tratta di salvare e poi ricaricare un gruppo di variabili su disco, con la differenza che nel caso delle impostazioni di progetto la posizione del file non è fissa.

Insomma, alla fine ho scritto un meccanismo di persistenza per le variabili di progetto, basato su una classe base SettingsBase. Quando ho una serie di variabili globali in un progetto che devono essere salvate e ricaricate su richiesta, non devo fare altro che derivare una classe da SettingsBase, chiamandola ad esempio Globals:

Public Class Globals
  Inherits SettingsBase

  Public Documents() As String ' Un array di nomi di documenti
  Public WordWrap As Boolen ' True se occorre applicare il word wrapping

  ' ...

End Class

Tutte le variabili Public in questa classe possono essere salvate e ricaricate da file semplicemente usando i metodi Load e Save che la classe eredita da SettingsBase. Poichè un overload di questi metodi accetta uno Stream, è anche possibile salvare e ricaricare da altri medium, ad esempio un campo di database.

Usare questo approccio per implementare anche il salvataggio e il caricamento delle impostazioni di utente e di applicazioni è banale, e infatti ho anche definito delle classi UserSettingsBase e ApplicationSettingsBase. Ereditando da queste classi astratte è possibile creare insiemi di variabili distinte per ciascun utente oppure condivise da tutti gli utenti della applicazione. Come accade per la classe My.Settings, le variabili sono automaticamente caricate alla partenza della applicazione e salvate prima di uscire. A differenza di My.Settings, è possibile salvare le impostazioni su database centralizzati (cosa molto comoda per supportare applicazioni smart client con centinaia di utenti che possono fare il login da qualunque stazione della rete). Ma soprattutto, a differenza di My.Settings, queste classi sono utilizzabili anche in Visual Basic 2003 (e più in generale in .NET 1.1).

Il codice delle classi SettingsBase, UserSettingsBase e ApplicationSettingsBase non è proprio banale, quindi ho pensato di commentarlo a dovere e di scriverci un articolo di accompagnamento. Alla fine ne è venuto fuori un testo di oltre 30K, che non era quindi molto adatto a un post di blog, per cui ho deciso di pubblicarlo nella sezione articoli del sito, insieme al codice sorgente completo, al seguente link

Diversi mesi fa mandai a Visual Studio Magazine un articolo su come usare custom attribute, form inheritance, e reflection per creare una infrastruttura per creare applicazioni WinForm estendibili mediante plug-in. Solo ora, con qualche mese di ritardo, mi accorgo che l'articolo è stato pubblicato online sul sito della rivista. Per leggere il testo completo occorre registrarsi, ma la registrazione è gratuita.

Il progetto di esempio include la libreria di estensibilità, una applicazione di esempio, e un piccolo plug-in di esempio. Per scrivere una applicazione estendibile basta ereditare i propri form dalla classe ExtensibileFormBase e, opzionalmente, visualizzare i form con il metodo statico FormExtenderManager.CreateForm. Il framework fornito a corredo permette di scrivere DLL che modificano a piacere i form usati dalla applicazionei principale (usando direttamente il designer di VS.NET) o addirittura di sostituire i form presenti della applicazione principale con form completamente differenti. E' un esempio piccolo ma completo (e abbastanza convincente) di quello che si può ottenere con i custom attribute.