Una delle tante cose che sono migliorate con .Net 2.0 è la gestione della localizzazione. Per default il fremework mette a disposizione i classici file di risorse (.resx), ma il modello è facilmente estendibile. Le risorse vengono suddivise in 2 categorie: Globali e locali. Le prime vengono definite creando un directory speciale nella root dell'applicazione (App_GlobalResources) e inserendo li i file di risorse con le localizzazioni. Il vantaggio che queste offrono rispetto alle risorse locali è che, grazie ad un BuildProvider, si ha a disposizione l'autocompletion nel codice. Se dichiariamo una variabile localizzata "NomeGruppo", basta scrivere nel codice Resources.NomeGruppo per ottenere il valore tradotto. Bello no ;). Le risorse locali sono quelle definite per ogni singola pagina e vengono definite in una directory speciale (App_LocalResources) creata nella stessa directory in cui si trova la pagina. Queste non hanno autocompletion e soprattutto essendo locali valgono solo per la pagina a cui si riferiscono, quindi non sono riutilizzabili. Infine nela pagina una nuova sintassi permette una facile associazione delle risorse (sia locali che gobali) alle proprietà dei contolli.

La vera bellezza di questo framework è che non è chiuso. Infatti utilizzando una bruttissima copia del ProviderModel, per cui il .NET 2.0 è famoso, è possibile utilizzare altre risorse per contenere i dati localizzati: file xml, database, ecc ecc. Alla base di tutto c'è la classe ResourceProviderFactory (da cui bisogna derivare) che contiene 2 metodi astratti che devono istanziare le classi che gestiscono le risorse private e quelle publiche. Queste classi devono implementare l'interfaccia IResourceProvider che dichiara i metodi che verranno chiamati al momento di localizzare i contenuti. Si può creare un BuildProvider ad-hoc per leggere le chiavi e creare l'autocompletion anche per la nostra risorsa custom. Nel web.config dell'applicazione si dichiara la classe di factory, l'eventuale BuildProvider ed il gioco è fatto.

Ma qui scatta la brutta copia del ProviderModel o l'AntiPattern se vogliamo. Se ho già una factory, perchè ereditare da questa e crearne un'altra per istanziare solo una determinata classe? Non ha senso. Avrebbe molto più senso che si definissero in fase di configurazione le 2 classi da istanziare dinamicamente e lasciarlo fare alla factory di base. Bah, certe cose della Class Library mi lasciano un pò perplesso. Ci voleva così poco...

Stay tuned...