Come gestisco la configurazione dell'applicazione in ASP.NET?

Question

Ho difficoltà a gestire la configurazione di un'applicazione ASP.Net da distribuire per client diversi. Il semplice volume di diverse impostazioni che necessitano di un po 'di tempo richiede molto tempo e gli attuali metodi di configurazione sono troppo complicati per consentirci di estendere questa responsabilità ai partner di supporto.

Qualche suggerimento per metodi migliori per gestire questa o buone fonti di informazioni per la ricerca?

come facciamo le cose attualmente:

• vari file di configurazione XML, che si fa riferimento nel web.config, ad esempio un AppSettings.xml.
• Le configurazioni per siti specifici sono conservate in file di configurazione duplicati.
• file di testo contenenti elenchi di dati specifici al sito
• In alcuni casi, manuali variazioni una tantum al database
• C# di configurazione per Windsor CIO.

Le questioni specifiche che stiamo avendo:

• siti diversi con caratteristiche diverse abilitate, diversi servizi esterni che dobbiamo parlare e regole di business differenti.
• Diversi tipi di distribuzione (dal vivo, di prova, di formazione)
• chiavi di configurazione cambiano tra versioni (vengono aggiunti, rimuovere), il che significa che dobbiamo aggiornare tutti i file duplicati
• Abbiamo ancora bisogno di essere in grado di alterare le chiavi, mentre l'applicazione è in esecuzione

I nostri pensieri correnti su come potremmo avvicinarci a questo sono:

• spostare la configurazione in codice compilato dinamicamente (possibilmente Boo, Binsor o JavaScript)
• hanno una qualche forma di diffing/fusione di configurazione: combinare una configurazione di default con un/test/config formazione dal vivo e un config site-specific

Answer 1

Se il codice utilizzando detta elementi di configurazione è il codice di gestire/possibile cambiare (e tutti in esecuzione nello spazio di codice gestito/C#) Vorrei cercare di eseguire il porting delle chiamate al metodo che ottengono le impostazioni di una chiamata in una classe simile a un singleton con almeno un metodo GetString() su di esso.

GetObject() può essere molto utile (controlla la documentazione di serializzazione XML .Net - gli americani lo scrivono con una "z": serializzazione) ... utile per molte cose ma anche perché significa che puoi iniziare a confezionare elementi di configurazione correlati in singole voci nel negozio.

Per quanto riguarda l'utilizzo di un singolo archivio (una tabella di database con accesso memorizzato nella cache) o utilizzare la nuova facciata di configurazione solo per incapsulare dove sono archiviati gli elementi di configurazione, dipende da voi ... Preferisco fortemente un singolo negozio per distribuzione del prodotto per la configurazione, perché allora sai sempre esattamente dove guardare e dove apportare modifiche. Tutti i riferimenti al servizio Web (WCF o altro) possono essere definiti e chiamati utilizzando stringhe fornite dal runtime ...:)

In termini di valori di memorizzazione nella cache per le chiavi, utilizzo il mio nella cache di memoria (per le app più piccole) perché il sovraccarico sullo stack è gestibile ... cose come memcache potrebbero funzionare qui (l'archivio di configurazione è accessibile tramite TCP/sulla rete da qualche parte) ...

EDIT Qualcosa di simile:

public class ConfigurationStore 
{ 
    private static ConfigurationStore _instance = null; 

    public static ConfigurationStore Instance { 
     get { 
     if(_instance == null) 
     { 
      _instance = new ConfigurationStore(); 
     } 

     return _instance; 
     } 
    } 

    public string GetValue(string key) 
    { 
     .... 
    } 

    public Object GetObject(string key) 
    { 
     ... 
    } 
} 

Answer 2

Si può prendere in considerazione guardando script NAnt per l'automazione in combinazione con una qualche utilità .net personalizzato per manipolare le chiavi di configurazione.

Answer 3

In qualsiasi modo si va, penso che potrebbe essere utile per avere l'idea di un unico "fonte di verità" per la configurazione.

duplicazione è bene, se è necessario fornire la configurazione di alcuni componenti nella loro forma specializzata.

Ma per mantenere la tua sanità mentale, penso che dovresti cercare di mirare ad avere un posto dove impostare tutta la configurazione pertinente alla tua applicazione, e quindi un meccanismo ben definito per la traduzione in voci all'interno di Web.config, e qualsiasi altro meccanismo di configurazione che devi supportare.

A seconda del livello di competenza dei partner di supporto (anche se non interromperanno l'XML), immagino che si possa anche voler fornire un'utilità GUI per consentire loro di ruotare tutte le manopole in questa configurazione di "sorgente di verità" file, con "Apply" avvia e esegue il codice di trasformazione/aggiornamento per apportare le modifiche necessarie agli amici di Web.config &.

Poi, per gestire la configurazione per i diversi siti/clienti, si dispone in teoria circa un file di configurazione da gestire.

Nota: In ASP.NET 4.0 sarà disponibile un meccanismo di trasformazione della configurazione build-time (vedere http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4-Config-Transformation-Files.aspx), che potrebbe semplificare questa attività. Sembra che tu possa usare questo con alcuni hack per progetti non web (vedi http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html).

Tuttavia, se è necessario apportare queste modifiche al momento dell'implementazione, è possibile essere bloccati con la scrittura di strumenti personalizzati per farlo, anche se sembra che le trasformazioni XDT potrebbero essere la scelta giusta per te, dato che vuoi essere in grado di aggiungere/aggiornare/rimuovere elementi.