Come passare al meglio le configurazioni globali come i dati di accesso?

Question

Come passare al meglio le configurazioni globali come i dati di accesso?

#1 da (2 voti)

0

Ho una base di codice composta da più script e molte funzioni. Tutto è controllato da uno script principale ( master.txt , diciamo).

Ho molti file di configurazione "globali", ad esempio l'URL, l'accesso e la password del servizio web con cui sto comunicando (questo cambia tra test e produzione) e alcuni parametri di ottimizzazione per un algoritmo di ottimizzazione nascosto in profondità all'interno degli altri script.

Voglio configurare questi parametri spesso, e preferibilmente facilmente. Qual è il modo migliore per farlo?

Finora, ho pensato alle seguenti opzioni:

Una variabile globale parameters definita all'inizio, che memorizza tutte queste opzioni ed è accessibile dall'interno delle funzioni profonde
Una variabile parameters definita all'inizio e passata come argomento di funzione aggiuntivo in ogni chiamata di funzione
Un file di testo come parameters.yaml che viene letto ogni volta che una funzione deve accedere a un valore da esso.

Attualmente sto usando la prima opzione, ma non mi sembra giusto, dato che le funzioni stanno accedendo ai dati che non sono passati a loro. D'altra parte, la seconda opzione rende ogni chiamata di funzione inutilmente complessa aggiungendo un argomento aggiuntivo.

Sicuramente non sono il primo ragazzo con questo problema e esiste una soluzione standard per questo, giusto?

globals parameters

posta Alexander Engelhardt 18.10.2017 - 14:46

fonte

1 risposta

Leggi altre domande sui tag globals parameters

architettura per l'applicazione Implementazione dell'interfaccia functor vs Funcion objects come membri C ++

score 2 · Accepted Answer

Un file esterno come la terza opzione è la best practice generale per la gestione delle informazioni di configurazione noto solo in fase di esecuzione e che deve essere modificato in base all'ambiente. Inoltre, piuttosto che leggere il file direttamente in ogni posizione, sono necessari i valori, sarebbe meglio creare una funzione getConfigValue che prende il nome del valore necessario e restituisce il valore se ne esiste uno nel file. Da qui puoi chiamare getConfigValue in ogni luogo in cui hai bisogno di un valore, o preferibilmente nel tuo master lo chiami per ottenere i valori necessari per una chiamata di funzione e fornirli come parametri alle funzioni che ne hanno bisogno. Potresti passare un oggetto parametro se ci sono diversi valori, ma la parte importante è solo popolarla con ciò di cui ha bisogno la funzione sottostante.

Potresti fare un ulteriore passo avanti e avere parameters.yaml riferimento secrets.yaml che contiene password o altri valori sensibili che non cambiano (o cambiano di rado) in uno stato crittografato. getConfigValue gestirà andando a secrets.yaml e crittografando il valore. Ci sono diversi motivi per farlo in questo modo:

così le informazioni sensibili possono essere escluse dai sistemi di controllo delle versioni
una persona diversa può gestire la crittografia dei valori in modo che gli sviluppatori non debbano conoscere i valori e possano comunque svolgere il loro lavoro
i valori devono essere memorizzati solo sulle macchine che ne hanno bisogno
chiunque abbia accesso al file system non può semplicemente visualizzare il file in uno stato utile

Ciò che non si vuole fare è creare un singolo oggetto parametro che contenga tutti i possibili valori di configurazione e trasmetterlo ovunque, questo crea un rischio maggiore per esporre potenzialmente le informazioni che non si vogliono mostrare perché si stanno mantenendo i valori in memoria più a lungo di quanto sia necessario e consentendo a qualsiasi funzione che può accedere all'oggetto parametro di accedere a qualsiasi valore, è possibile modificare o rivelare involontariamente valori sensibili.