Config Class / Struct: Pattern o Anti-Pattern? Alternative?

La soluzione migliore sarebbe quella di creare diverse interfacce di configurazione e implementarle come desideri. Ciò limita entrambi l'accessibilità e mantiene le cose localizzate. Tuttavia, è troppo difficile per essere valsa la pena semplicemente buttando tutto il config in una singola classe e passare a un problema con molto più gravitas. Questa è la configurazione, non quella di UtterlyCrucialAlwaysChangingClass, praticamente rimarrà la stessa. Fintanto che non rendi tutto globale e l'implementazione è coerente, non me ne preoccuperei.

Preferisco l'opzione 1 perché il disaccoppiamento consente una verifica più semplice e le impostazioni di configurazione di cui l'oggetto dipende sono esplicitate. Se un oggetto richiede un'impostazione di configurazione, fornirlo esplicitamente all'oggetto tramite un argomento costruttore o un metodo setter. Riduci la verbosità utilizzando un framework di iniezione delle dipendenze per iniettare tali impostazioni di configurazione nell'oggetto.

Immagina se il tuo file di configurazione fosse scritto in XML. Potresti quindi passare i frammenti di questo XML a ciascuno dei tuoi componenti, in modo che ottengano i loro dati di configurazione.

Se si utilizza .NET, è possibile creare classi con DataContracts che è possibile utilizzare XmlSerialiser per creare una gerarchia di oggetti dall'Xml di configurazione e passare questi oggetti come configurazione.

Questo ti introduce al prossimo problema. I dati di configurazione hanno tre parti differenti. La configurazione dell'applicazione strutturale che organizza le tue librerie di codici per comportarsi come questo prodotto specifico. Impostazioni di configurazione del sito che contengono le impostazioni specifiche dell'installazione e le preferenze utente / i dati delle impostazioni che varia con ciascun utente sul sistema.

Sapendo quale parte è e mantenendo separate queste impostazioni dei dati, l'installazione degli aggiornamenti sarà molto più semplice (senza perdere le impostazioni dei clienti)

Renderei la classe nell'opzione # 3 statica. Quindi invece di

//create SomeCl
Foo f = new Foo();
f.setConfigInst(cfg);
...
...
//Inside Foo
public void setConfig(MyAppConfig c) { localCfg = c; }
...
//somewhere else:
x = localCfg.getConfigForX();

Puoi semplicemente avere:

//Inside Foo
x = MyAppConfig.getConfigForX();

Lascia che i dettagli del caricamento / salvataggio dei dati di configurazione avvengano all'interno della classe MyAppConfig . E naturalmente potresti avere variazioni più complesse, come classi diverse per scopi diversi.

L'unico caso in cui questo approccio sarebbe un problema sarebbe se per qualche motivo dovessi lavorare su più istanze di configurazioni differenti allo stesso tempo , anche se devo ancora imbattermi in tale situazione.

Sto lavorando a un progetto in cui utilizziamo l'approccio "3 livelli (interfaccia, business logic, accesso ai dati)". L'applicazione può essere un server web multiutente o un server client.

Lavoriamo con 3 diverse configurazioni, la prima specifica per la P.C., mentre l'utente sta lavorando. Il secondo specifico per l'utente corrente e una terza configurazione globale per tutti gli utenti e amp; app client.

Ogni configurazione è rappresentata in ogni istanza dell'applicazione da un oggetto.

Questo approccio può aiutare il tuo progetto.