Sezioni custom nel file “.config”
Una delle prime cose che ho apprezzato anni addietro passando da Visuali Basic 6.0 a .NET, è la gestione dei file di configurazione; I vecchi file “.ini” presenti in VB6 avevano (finalmente, diciamocelo) lasciato spazio a file xml in grado di esprimere ben più di una sfilza senza fine di coppie “chiave/valore”.
Ciononostante per lungo tempo, come molti neofiniti, ho utilizzato la sezione “appSettings” del file “.config” esattamente come prima: nessun beneficio, dato che è come “sparare alle mosche con un cannone”...
La situazione sembrava essere sotto controllo fino al giorno in cui uno dei miei progetti era cresciuto a dismisura, e il livello di customizzazioni che era in grado di gestire, si aggirava nell’ordine delle centinaia. “Ma possibile che non esiste un modo più furbo (e logico) di salvare i settings?”.
Chiaramente, si (solo che ero troppo “newbie” per saperlo").
Prima di tutto aggiungiamo una bellissima sezione personalizzata in “configSection"… ...dove “chimera” rappresenta il nome della nuova sezione di configurazione per una ipotetica applicazione “Chimera”, e il type rappresenta il namespace completo di una classe che servirà per gestire tale configurazione (…da non dimenticare l’assembly in cui la classe è contenuta “Chimera.Core”).
Fatto questo possiamo includere nel file di configurazione la sezione personalizzata… La classe di riferimento per la gestione “in code” della configurazione è questa: E’ possibile includere in configurazione sia valori semplici (es. la proprietà “title” sul primo livello") che sotto-sezioni semplici o multiple (es. la proprietà “timing” legata alla classe “TimingConfiguration”; per ciascun elemento è inoltre possibile specificare se tale dato è obbligatorio e, in caso negativo, qual’è il suo valore di default.
La cosa “figa” di tutto questo è che, in fase di esecuzione, la configurazione dell’applicazione non rispetta lo schema dato, .NET è in grado di emettere un’eccezione chiarissima, che indica il punto esatto in cui tale configurazione non rispetta lo schema.
Leggere le configurazioni da codice è altrattento semplice: basta istanziare la classe “root” della vostra configurazione (o utilizzare la classe statica “ConfigurationManager”) per poter accedere a tutti I valori che avete inserito nel vostro file “.config”.
Il consiglio che mi sento di dare è di scrivere configurazioni raggruppando il più possibile “settings” che hanno una correlazione logica tra loro, evitando di far proliferare delle configurazioni senza senso e difficili da comprendere.
Buon divertimento…
Ciononostante per lungo tempo, come molti neofiniti, ho utilizzato la sezione “appSettings” del file “.config” esattamente come prima: nessun beneficio, dato che è come “sparare alle mosche con un cannone”...
La situazione sembrava essere sotto controllo fino al giorno in cui uno dei miei progetti era cresciuto a dismisura, e il livello di customizzazioni che era in grado di gestire, si aggirava nell’ordine delle centinaia. “Ma possibile che non esiste un modo più furbo (e logico) di salvare i settings?”.
Chiaramente, si (solo che ero troppo “newbie” per saperlo").
Prima di tutto aggiungiamo una bellissima sezione personalizzata in “configSection"… ...dove “chimera” rappresenta il nome della nuova sezione di configurazione per una ipotetica applicazione “Chimera”, e il type rappresenta il namespace completo di una classe che servirà per gestire tale configurazione (…da non dimenticare l’assembly in cui la classe è contenuta “Chimera.Core”).
Fatto questo possiamo includere nel file di configurazione la sezione personalizzata… La classe di riferimento per la gestione “in code” della configurazione è questa: E’ possibile includere in configurazione sia valori semplici (es. la proprietà “title” sul primo livello") che sotto-sezioni semplici o multiple (es. la proprietà “timing” legata alla classe “TimingConfiguration”; per ciascun elemento è inoltre possibile specificare se tale dato è obbligatorio e, in caso negativo, qual’è il suo valore di default.
La cosa “figa” di tutto questo è che, in fase di esecuzione, la configurazione dell’applicazione non rispetta lo schema dato, .NET è in grado di emettere un’eccezione chiarissima, che indica il punto esatto in cui tale configurazione non rispetta lo schema.
Leggere le configurazioni da codice è altrattento semplice: basta istanziare la classe “root” della vostra configurazione (o utilizzare la classe statica “ConfigurationManager”) per poter accedere a tutti I valori che avete inserito nel vostro file “.config”.
Il consiglio che mi sento di dare è di scrivere configurazioni raggruppando il più possibile “settings” che hanno una correlazione logica tra loro, evitando di far proliferare delle configurazioni senza senso e difficili da comprendere.
Buon divertimento…
Commenti
Posta un commento