Comprendere le opzioni di configurazione di .Net

Question

Sono davvero confuso dalle varie opzioni di configurazione per la configurazione .Net di DLL, siti Web ASP.net ecc. in .Net v2, soprattutto se si considera l'impatto di un file di configurazione all'estremità dell'interfaccia utente/utente finale della catena.

Quindi, ad esempio, alcune delle applicazioni con cui lavoro utilizzano impostazioni a cui accediamo con:

string blah = AppLib.Properties.Settings.Default.TemplatePath;

Ora, questa opzione sembra interessante perché i membri sono digitati in modo forte e non sarò in grado di digitare un nome di proprietà che non esiste nell'IDE di Visual Studio 2005.Ci ritroveremo con righe come questa nell'App.Config di un progetto eseguibile da riga di comando:

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(Se non abbiamo la seconda impostazione, qualcuno che ha rilasciato una dll di debug sulla live box potrebbe averla creata con la stringa di connessione di debug incorporata al suo interno - eek)

Abbiamo anche accesso alle impostazioni in questo modo:

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

Ora, sembrano interessanti perché possiamo accedere alle impostazioni dal codice dll o dal codice exe/aspx e tutto ciò di cui abbiamo bisogno nel Web o in App.config è:

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

Tuttavia, il valore ovviamente potrebbe non essere impostato nei file di configurazione o il nome della stringa potrebbe essere digitato in modo errato, quindi abbiamo una serie di problemi diversi.

COSÌ...se ho capito bene, i primi metodi forniscono una tipizzazione forte ma una cattiva condivisione dei valori tra la DLL e altri progetti.Quest'ultimo fornisce una migliore condivisione, ma una digitazione più debole.

Sento che mi manca qualcosa.Per il momento, non mi preoccupa nemmeno che l'applicazione sia in grado di riscrivere i valori nei file di configurazione, crittografia o qualcosa del genere.Inoltre, avevo deciso che il modo migliore per archiviare eventuali stringhe non di connessione era nel DB...e poi la cosa successiva che devo fare è memorizzare i numeri di telefono per inviare messaggi alle persone in caso di problemi di connessione al DB, quindi devono essere archiviati al di fuori del DB!

Answer 1

No, la nostra differenza nel modo di pensare deriva dalle nostre diverse prospettive.Sto pensando di sviluppare app aziendali che utilizzino prevalentemente client WinForms.In questo caso la logica aziendale è contenuta in un server delle applicazioni.Ogni client dovrebbe conoscere il numero di telefono da comporre, ma inserirlo nell'App.config di ciascun client pone un problema se il numero di telefono cambia.In tal caso sembra ovvio archiviare le informazioni sulla configurazione dell'applicazione (o le impostazioni a livello di applicazione) in un database e fare in modo che ciascun client legga le impostazioni da lì.

L'altro metodo .NET (faccio la distinzione perché, prima di .NET, memorizzavamo le impostazioni dell'applicazione nelle tabelle DB) consiste nel memorizzare le impostazioni dell'applicazione nel file app.config e accedervi tramite la classe Impostazioni generata .

Io divago.La tua situazione sembra diversa.Se tutte le diverse app si trovano sullo stesso server, potresti posizionare le impostazioni in un web.config a un livello superiore.Tuttavia, se non lo sono, potresti anche avere un "servizio di configurazione" separato con cui tutte e tre le applicazioni comunicano per ottenere le impostazioni condivise.Almeno in questa soluzione non stai replicando il codice in tre posti, aumentando il potenziale di problemi di manutenzione durante l'aggiunta delle impostazioni.Sembra un po' troppo ingegnerizzato però.

La mia preferenza personale è quella di utilizzare impostazioni di digitazione forti.In realtà genero la mia classe di impostazioni fortemente tipizzata in base alla tabella delle impostazioni nel database.In questo modo posso avere il meglio di entrambi i mondi.Intellisense alle mie impostazioni e alle impostazioni memorizzate nel db (nota:questo è il caso in cui non è presente un server app).

Sono interessato anche a imparare le strategie di altre persone per questo :)

Answer 2

Se utilizzi la scheda Impostazioni in VS 2005+, puoi aggiungere impostazioni fortemente tipizzate e ottenere IntelliSense, come nel tuo primo esempio.

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

Questo è fisicamente archiviato in App.Config.

Potresti comunque utilizzare l'elemento appSettings del file di configurazione o persino creare le tue sottoclassi ConfigurationElementCollection, ConfigurationElement e ConfigurationSection.

Per quanto riguarda dove archiviare le impostazioni, il database o il file di configurazione, nel caso di stringhe non di connessione:Dipende dall'architettura dell'applicazione.Se disponi di un server delle applicazioni condiviso da tutti i client, utilizza il metodo sopra menzionato in App.Config sul server delle applicazioni.Altrimenti potrebbe essere necessario utilizzare un database.Inserendolo in App.Config su ogni client causerà problemi di controllo delle versioni/distribuzione.

Answer 3

Penso che la tua confusione derivi dal fatto che sembra che il tuo primo esempio sia una libreria fatta in casa, non parte di .NET.L'esempio del gestore della configurazione è un esempio di funzionalità integrata.

Answer 4

Sostengo la risposta di Rob Gray, ma volevo aggiungerla leggermente.Ciò potrebbe essere eccessivamente ovvio, ma se si utilizzano più client, app.config dovrebbe memorizzare tutte le impostazioni specifiche dell'installazione e il database dovrebbe memorizzare praticamente tutto il resto.

Le app client (o server) singole sono leggermente diverse.Qui è davvero una scelta più personale.Un'eccezione notevole sarebbe se l'impostazione fosse l'ID di un record nel database, nel qual caso memorizzerei sempre l'impostazione In il database con una chiave esterna per garantire che il riferimento non venga eliminato.

Answer 5

Sì, penso che io/noi siamo nella situazione di mal di testa descritta da Rob: abbiamo qualcosa come 5 o 6 diversi siti Web e applicazioni su tre server indipendenti che devono accedere allo stesso DB.Allo stato attuale, ognuno ha il proprio Web o App.config con le impostazioni descritte come impostazione e/o sostituzione delle impostazioni nella nostra libreria dll di accesso al DB principale.

Rob, quando dici server delle applicazioni, non sono sicuro di cosa intendi?La cosa più vicina che riesco a pensare è che potremmo almeno condividere alcune impostazioni tra siti sulla stessa macchina inserendole in un web.config più in alto nella gerarchia delle directory...ma anche su questo non ho potuto indagare...avendo ritenuto più importante capire quale dei percorsi di tipo forte o debole sia "migliore".