Quale metodo di configurazione preferisci in .net? Perché? [chiuso]

Question

• Puoi usare App.config; ma supporta solo coppie chiave / valore.
• È possibile utilizzare la configurazione .Net, sezioni di configurazione; ma può essere davvero complesso.
• Puoi usare la serializzazione / deserializzazione Xml da solo; le tue lezioni a modo tuo.
• Puoi usare qualche altro metodo; cosa possono essere? ...

Quale di questi o altri metodi (se ce ne sono) preferisci? Perché?

Answer 1

Quando le coppie chiave-valore non sono sufficienti, utilizzo le sezioni di configurazione in quanto non sono complesse da utilizzare (a meno che non sia necessaria una sezione complessa):

Definisci la tua sezione personalizzata:

        public class CustomSection : ConfigurationSection
        {
            [ConfigurationProperty("LastName", IsRequired = true,
            DefaultValue = "TEST")]
            public String LastName
            {
                get { return (String)base["LastName"]; }
                set { base["LastName"] = value; }
            }

            [ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
            "TEST")]
            public String FirstName
            {
                get { return (String)base["FirstName"]; }
                set { base["FirstName"] = value; }
            }

            public CustomSection()
            {

            }
        }

Crea a livello di codice la tua sezione (se non esiste già):

           // Create a custom section.
            static void CreateSection()
            {
                try
                {

                    CustomSection customSection;

                    // Get the current configuration file.
                    System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

                    // Create the section entry  
                    // in the <configSections> and the 
                    // related target section in <configuration>.
                    if (config.Sections["CustomSection"] == null)
                    {
                        customSection = new CustomSection();
                        config.Sections.Add("CustomSection", customSection);
                        customSection.SectionInformation.ForceSave = true;
                        config.Save(ConfigurationSaveMode.Full);
                    }
                }
                catch (ConfigurationErrorsException err)
                {
                    //manage exception - give feedback or whatever
                }

            }

Dopo la definizione di CustomSection e l'effettiva CustomSection verranno creati per te:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
  </configSections>
  <CustomSection LastName="TEST" FirstName="TEST" />
</configuration>

Ora recupera le proprietà della sezione:

    CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
    string lastName = section.LastName;
    string firstName = section.FirstName;

Answer 2

Se riesco a cavarmela, userò semplicemente App.Config, tuttavia, se avrò bisogno di qualcosa di più complesso, userò sezioni di configurazione personalizzate. Sì, all'inizio è difficile capire, ma una fonte di configurazione unificata e una configurazione familiare per tutte le impostazioni valgono il tempo investito secondo me.

Answer 3

Metti la tua configurazione in un database. Se esegui la tua app su più di una macchina (ad esempio un'app client-server), tutti i sistemi di configurazione per macchina sono una PITA. Una singola area di configurazione è il modo migliore per posizionare la configurazione. Scrivi una GUI per gestirla e sarai molto felice.

Distribuire i file app.config in 200 caselle client .. non è divertente, specialmente quando ci si perde (e lo fanno, credimi).

Answer 4

In passato ero un amministratore di rete / sistema e ora sviluppo utilità interne per applicazioni di database. Quello che ho trovato è questo:

I semplici file di configurazione non nidificati sono i migliori per le applicazioni che non cambieranno dove accedono molto alle loro risorse.

Qualunque cosa più complessa deve andare in un database con un'interfaccia utente di amministrazione. Questo vale solo per i normali utenti aziendali. Se sei preoccupato che il database venga danneggiato, utilizza l'approccio del file di configurazione complesso. I file tendono a corrompere meno dei database.

Ora, se i tuoi utenti sono altri sviluppatori, avrai molta più flessibilità su cosa usare per memorizzare le tue configurazioni.

Answer 5

Trovo NameValueCollectionHandler il più semplice e meglio, e in genere vorrei collegarmi a un file di configurazione esterno tramite l'attributo configSource.

Provo a inserire la configurazione ABSOLUTE MINIMUM in file di configurazione, con la maggior parte configurata in codice con un'applicazione che è autocosciente del suo ambiente di distribuzione (come per esempio nome macchina o indirizzo IP se noto). Naturalmente ciò ha richiesto molta più pre-pianificazione e conoscenza dei tuoi ambienti, ma molto meno mal di testa durante la distribuzione.

Answer 6

Uso un file di configurazione XML personalizzato, in cui viene utilizzato un file di configurazione diverso per ciascun ambiente (dev / qa / prod). I file di configurazione sono modelli che vengono istanziati in modo dinamico con elementi come le configurazioni host / porta per i servizi: questo rende multi ambienti e failover molto semplici in quanto possono essere gestiti dal codice di istanza del modello.

Naturalmente se hai pochissima configurazione e non ti preoccupi di più ambienti, app.config è più standard ed è probabilmente il modo migliore di procedere.

Answer 7

I configurazioni chiave / valore funzionano piuttosto bene per file di configurazioni semplici. Diventa un problema quando il file inizia a crescere e difficile da mantenere. Abbiamo iniziato a dividere il file di configurazione in " common " e "specifico" configurazioni delle applicazioni. L'accesso ai file è trasparente per l'app, " comune " i valori sono gli stessi nella maggior parte dei casi, ma "specifici" differisce per ogni applicazione distribuita.

Answer 8

Uso un file di configurazione XML personalizzato. Ogni impostazione ha una chiave, un valore e un tipo.

Ha una sezione principale che contiene tutte le impostazioni e sezioni aggiuntive contenenti le sostituzioni delle impostazioni per ambienti particolari (sviluppo, gestione temporanea, live). Questo non ho bisogno di sostituire sezioni del file durante la distribuzione. Ho un piccolo wrapper che puoi chiamare per ottenere un'impostazione particolare o un dizionario che li contiene tutti.

Di recente ho creato un modello T4 che leggere il file di configurazione e creare una classe di impostazioni statiche fortemente tipizzate. È stato un enorme risparmio di tempo.

Answer 9

Conservo la maggior parte della mia configurazione nel contenitore IoC, ad es. Spring.Net.

Answer 10

Se hai .NET 3.0 disponibile, trovo XamlReader / XamlWriter molto utile per la memorizzazione delle impostazioni. Possono scrivere / leggere qualsiasi oggetto .NET su XAML se:

• L'oggetto ha un costruttore senza parametri
• Le proprietà da leggere / scrivere hanno getter e setter pubblici

È particolarmente bello non dover decorare gli oggetti delle impostazioni con alcun attributo.

Answer 11

dataset.WriteXML () / dataset.ReadXML () funziona abbastanza bene per me quando app.config non lo taglia più.

Answer 12

Principalmente preferisco usare il file xml personalizzato e il metodo di serializzazione Xml per leggere e scrivere questo file di configurazione ... Non limitato a coppie chiave / valore e non complesso da implementare ...

Answer 13

Ho avuto fortuna a lanciare la mia classe speciale che restituisce i dati di configurazione da un " .settings " file associato all'assembly chiamante. Il file è XML e la classe settings lo espone pubblicamente come XDocument. Inoltre, l'indicizzatore per questa classe di impostazioni restituisce i valori degli elementi da / settings / setting nodes.

Funziona alla grande per applicazioni semplici in cui è necessario solo un accesso chiave / valore alle impostazioni e funziona perfettamente per le impostazioni complicate in cui è necessario definire la propria struttura e utilizzare System.Xml.Linq per interrogare il documento XML.

Un altro vantaggio del roll-up è la possibilità di utilizzare FileSystemWatcher e il tipo di azione callback per attivare automaticamente un metodo quando il file cambia in fase di esecuzione.