IConfiguartionSectionHandler... in lista per la deprecazione! :(

IConfiguartionSectionHandler e la possibilità di customizzare sezioni del file di configurazione è una della cose che mi sono sempre piaciute! Con la nuova versione del framework e i generics è/sarebbe possibile scrivere devvero velocemente un IConfiguartionSectionHandler, ecco come faccio:

  1. Defisco lo schema xsd della mia sezione (MySectionSchema.xsd)
  2. Genero le classi per la sezializzazione (MySectionSchema.cs) con xsd.exe, che ho a portata di menù  
  3. Definisco il mio handler sfruttando una classe base così definita:
    public abstract class ConfigurationSectionHandler<T> : IConfigurationSectionHandler
    {
      #region IConfigurationSectionHandler Members
      object IConfigurationSectionHandler.Create(object parent, object configContext, System.Xml.XmlNode section)
      {
        XmlSerializer ser = new XmlSerializer(typeof(T), new XmlRootAttribute(section.Name));
        XmlNodeReader reader = new XmlNodeReader(section);
        return ser.Deserialize(reader);
      }
      #endregion
    }
    

    ...la classe così fatta potrebbe dare dei problemi in caso di namespace specializzati per cui per fare le cose fatte bene si potrebbe/dovrebbe scrivere anche così:

    public abstract class ConfigurationSectionHandler<T> : IConfigurationSectionHandler
    {
      #region IConfigurationSectionHandler Members
      object IConfigurationSectionHandler.Create(object parent, object configContext, System.Xml.XmlNode section)
      {
        XmlSerializer ser = new XmlSerializer(
            typeof(T), 
            new XmlAttributeOverrides(), 
            new Type[]{}, 
            new XmlRootAttribute(section.Name), 
            section.NamespaceURI);
        XmlNodeReader reader = new XmlNodeReader(section);
        return ser.Deserialize(reader);
      }
      #endregion
    }
    
  4. Una Riga per la definizione della classe concreta:
    public class MyConfigSectionHandler: ConfigurationSectionHandler<MySectionSchema>{}

Purtoppo a volte uno è tutto intento nel scoprire le funzionalità tanto pubblicizzate del nuovo framework che le cose banali/marginali finisco per sfuggirgli. E infatti qualche settimana fà discutendo sul newsgroup ho avuto la tremenda notizia che tale modalità di operare verrà deprecata anche se le classi non sono marcate come Obsolete... e infatti sul MSDN tristemente leggo:

"This topic uses the System.Configuration.IConfigurationSectionHandler interface, which has been deprecated in the .NET Framework version 2.0. For an example that uses the System.Configuration.ConfigurationSection class, see How to: Create Custom Configuration Sections Using ConfigurationSection. If you use the following code examples, please build them with the .NET Framework version 1.0 or 1.1." (http://msdn2.microsoft.com/en-us/library/ms228056.aspx)

Si certo esistono le nuove classi per la gestione del config sono ben fatte e piene di nuove potenzialità ma come ho detto in un mio suggerimento su lady bug, "IConfiguartionSectionHandler, why deprecated?" non capisco perchè deprecare tale modalità in quanto comunque è sistema pratico e veloce... sebbene gli esempi di MSDN lo facciamo apparire ostico e avanzato! Quindi perchè non matenere tutte e due le possibilità? Beh comunque qualcuno mi ha risposto - non so se per cortesia o perchè davvero interssato - dicendo che terranno in considarazione - a momento debito - il mio suggerimento... bah incrociamo le dita :-p Lunga vita a IConfigurationSectionHandler!

posted @ martedì 31 gennaio 2006 16:36

Print

Comments on this entry:

# re: IConfiguartionSectionHandler... in lista per la deprecazione! :(

Left by Fabio Cozzolino at 31/01/2006 16:45
Gravatar
Concordo e sottoscrivo !! ;-)

# re: IConfiguartionSectionHandler... in lista per la deprecazione! :(

Left by nostromo at 31/01/2006 17:36
Gravatar
personalmente preferisco il nuovo mofrllo dichirativo, è possibile creare sezioni di configurazione molto più velocemente, eliminanando la scrittura di codice spesso ripetitivo

# re: IConfiguartionSectionHandler... in lista per la deprecazione! :(

Left by M.rkino at 31/01/2006 18:00
Gravatar
In che senso ripetitivo... forse la cosa è vera per il framework 1.1 ma per il framework 2.0 l'handler, unico punto ripetitivo, è definibile - come da mio esmepio - in una veloce riga. Ovviamente la classe base è da mettere nella classica lib common. La nuova struttura è fantastica, ha un sacco di novità, si integra con l'editor del framework... etc... etc... ma la maggior parte delle volte mi sembra che mi costringa a definire un sacco di cose che per i miei casi d'uso non mi interessano. Per cui - IMHO - non dico meglio prima che ora ma semplicemente sarebbe interssante avere tutte e due le possibilità così da non complicate la dove potrebbe essere semplice... ;-p

# re: IConfiguartionSectionHandler... in lista per la deprecazione! :(

Left by Pierre Greborio at 31/01/2006 18:04
Gravatar
Faccio l'avvocato del diavolo.

Sebbene con la versione 1.x del framework abbia utilizzato/proposto più volte la modalità da te sottoposta, con il framework 2.0 ritrovo tre vantaggi nell'usare la nuova modalità:

1. Posso gestire i default

2. Se manca un elemento me ne accorgo (il deserializzatore xml è a volte troppo libertino)

3. La deserializzazione ha un suo peso.

# re: IConfiguartionSectionHandler... in lista per la deprecazione! :(

Left by M.rkino at 31/01/2006 18:21
Gravatar
Si hai ragione Pierre... concordo con i punti 1 e 2. I default sono comunque gestibili con l'attributo DefaultValue mentre per scovare gli elememti non specificati si tratta di ben definire lo schema XSD e di conseguenza le classi per la serializzazione definiranno i campi "bool xSpecified". Concordo comunque che la serializzazione è a volte un pò libertina.
Per il punto 3 è vero ma dato l'uso limitato che si dovrebbe fare della lettura del file di configurazione considero il peso come irrilevente...
Comments have been closed on this topic.
«dicembre»
domlunmarmergiovensab
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234