Ho sentito dire che non è così, ma non suggeriscono mai un'alternativa. È vero?
UPDATE È possibile memorizzare questo esterno dall'applicazione e farlo chiamare?
Negli ambienti Enterprise, l'archiviazione di qualsiasi tipo di credenziali (chiavi / nomi utente, ecc.) nelle applicazioni è strongmente sconsigliata.
Tutte queste credenziali dovrebbero essere archiviate su:
In questo modo puoi applicare ACL * su questi. E solo l'id utente che esegue queste app dovrebbe avere accesso a questi. Ad esempio, puoi creare ID utente "accounting_producion" o "accounting_qa". E l'app dovrebbe funzionare come questi utenti. E solo questi utenti + utenti di supporto dovrebbero avere accesso alle configurazioni.
E qualsiasi modifica può essere rapidamente propagata attraverso tutte le istanze.
ACL - > Elenchi di controllo di accesso
Considera cosa accadrebbe se aggiorni una chiave o un ID - vuoi davvero ricompilare e ridistribuire un nuovo binario?
Di solito è molto più semplice conservare questo tipo di dati in un file di configurazione separato che può essere aggiornato più facilmente.
Io voterei sicuramente nella configurazione - probabilmente vorrai, almeno, avere una chiave diversa per dev e / o staging. Averlo nel file di configurazione ha più senso in quanto questo è in genere diverso per ogni ambiente.
Nota che se stiamo parlando di un ambiente compilato vs compilato, detto file di configurazione potrebbe essere qualsiasi lingua tu stia utilizzando piuttosto che xml / yaml / json / .ini / qualsiasi formato tu abbia appena creato.
Alla luce del tuo commento, considera questa domanda in termini di una chiave API: hai intenzione di assegnare la stessa chiave a ogni utente della tua API?
Considera uno scenario in cui sei stato attaccato. Puoi isolare l'origine dell'attacco per indirizzo IP e vedere che proviene da un'azienda che ha accesso alla tua chiave API. Devi presumere che la loro chiave sia stata compromessa. Tuttavia, se la chiave API è codificata, sarà necessario modificare la chiave API nell'applicazione, ridistribuire l'applicazione a tutti i clienti e assicurarsi che tutte le applicazioni / servizi dei clienti che fanno affidamento sulla propria API siano state modificate per gestire la nuova chiave API.
Questo è un costo sia per la tua azienda che per i tuoi clienti; potrebbe influenzare negativamente la tua relazione con i tuoi clienti.
Se, invece, memorizzi le chiavi API in un database, una per cliente, puoi semplicemente eseguire una singola query SQL e risolvere il problema.
In genere cerco di ottenere tutto ciò che dipende dall'ambiente dall'applicazione. Non ho eseguito un articolo di configurazione simile a quello elencato che deve essere presente nell'applicazione per motivi tecnici. Sembra che tu stia cercando le tue opzioni.
Molti elementi sono adatti per essere inseriti in un file di configurazione. Il resto degli elementi dovrebbe funzionare bene quando inserito nel database delle applicazioni.
Alcuni ambienti di runtime contengono variabili e / o argomenti della riga di comando che l'applicazione può leggere. Queste sono una buona scelta per gli elementi di configurazione che potresti dover sovrascrivere per una determinata esecuzione.
L'inserimento di elementi di configurazione nell'applicazione significa che è necessario disporre di compilazioni specifiche per l'ambiente. Ciò può causare problemi che possono essere replicati solo in un ambiente, perché questo è l'unico ambiente con il codice danneggiato. Rischia anche che venga creata la versione sbagliata per il prossimo ambiente.
Certo che lo è - specialmente se si tratta di un linguaggio decompilabile basato su VM, come Java o C # ...:)