L'uso corretto del file application.properties?

Question

L'uso corretto del file application.properties?

#1 da (5 voti)

6

I programmatori Java sono incoraggiati a memorizzare tutti i loro parametri configurabili in un file application.properties dal quale caricano le proprietà durante il runtime o caricano durante l'avvio del programma e li assegnano alle variabili in un file di configurazione.

Il modo in cui l'ho usato è stato quello di memorizzare valori variabili che ho bisogno di modificare tra le esecuzioni del programma. Ho anche usato per archiviare stringhe di connessione al database e nomi di dominio del database in application.properties , ma di recente li ho spostati nel codice perché è stato difficile commentare più righe quando si è scelto di passare da un server locale a un server di produzione.

sql.connString=someProductionString
#sql.connString=someLocalhostString
sql.domain=productionDB
#sql.domain=localhost
mongo.connString=someProductionString
#mongo.connString=someLocalhostString
mongo.domain=productionDB
#mongo.domain=localhost

Era più facile avere le righe precedenti all'interno del codice e cambiare solo una riga domain.isRunningOnLocal=true in application.properties .

Tuttavia, il mio capo dice:
1. Le stringhe di connessione al database dovrebbero essere in application.properties stesso, poiché un altro sviluppatore che collabora sul mio codice troverebbe facile sapere quali sono quelle stringhe.
2. Dice anche che se ho delle variabili che devo modificare tra le esecuzioni del programma, dovrebbero essere inserite nel codice, all'interno dell'oggetto che utilizza tali variabili.
3. Quando il tester o la persona QA utilizza il mio progetto, sostituiscono il mio file application.properties con un proprio file application.properties che sarebbe rilevante per l'ambiente su cui sta eseguendo il programma.

Ha esplicitamente detto che devo dare la priorità a queste convenzioni al di sopra della mia convenienza e che solo le variabili generiche devono essere memorizzate in application.properties ; tutte le altre variabili devono essere memorizzate localmente all'oggetto che le utilizza. Apparentemente, ci sono molti progetti open source che usano il file delle proprietà in un certo modo.

Non lo compro perché tutte le ragioni sopra indicate perdono tempo. Perché passare del tempo a commentare e decomprimere linee e / o modificare variabili nel codice e ricompilare?

Esiste un modo consigliato di utilizzare application.properties ?

java conventions properties

posta Nav 07.03.2017 - 10:54

fonte

1 risposta

Leggi altre domande sui tag java conventions properties

Che cos'è il "codice basso"? Shoud Lancio le eccezioni al livello dell'interfaccia utente o le gestisco nel mio livello VM

score 5 · Accepted Answer

In un'applicazione server ben progettata, i dati di configurazione specifici per l'ambiente devono essere esternalizzati dall'app stessa (ad es. jar o file war), quindi non è necessario ricostruire l'app per ogni ambiente In genere, un'applicazione seria deve essere eseguita in una varietà di ambienti (locale, test, demo, produzione, varie distribuzioni client, sito di backup geograficamente ridondante, ecc.). Quindi, se c'è un file application.properties nell'app stessa, dovrebbe contenere solo valori predefiniti e dovrebbe esserci modo di sovrascrivere tali valori nell'ambiente.

In un'applicazione Spring Boot , ad esempio, ci sono diversi punti in cui può leggere un file application.properties come la directory di lavoro corrente e lo userà per sovrascrivere i valori da un file application.properties sul classpath. Supporta anche il concetto di profili, quindi è possibile selezionare tra diverse versioni di un file application.properties all'interno dell'app tramite un argomento della riga di comando (e comunque sovrascriverlo con un'applicazione esterna.properties).

La linea di fondo è : dovresti chiedere al tuo capo il modo migliore per sostituire i valori nei file application.properties dell'app senza ricostruire, in modo che tu possa essere configurato correttamente per essere eseguito localmente. Se dice che non c'è modo, chiederei di ottenerne uno implementato. È pazzesco dover mantenere un file modificato dall'archivio del codice in perenne solo per essere eseguito localmente.

Per inciso, e ovviamente dipende dall'architettura specifica ma, penso che sia di solito una cattiva idea memorizzare le credenziali di produzione reali nella linea di base del codice perché se qualcuno ottiene una copia del codice che ora può avere accesso a dati di produzione e la possibilità di eliminarli tutti.