Memorizza le configurazioni in memoria più prestazioni e manutenzione efficiente? [chiuso]

I'm not talking about which code will be better, rather I want to know if one way is more efficient than the other.

Allora stai parlando della cosa sbagliata.

Le prestazioni di questo non avranno importanza, mai, in alcun modo.

Cioè, a meno che tu non faccia qualcosa di stupido, come memorizzarlo in un file o database e leggerlo da lì ogni volta che ti servono le opzioni di configurazione. Sarebbe male.

Se non lo incasini, la configurazione verrà letta una volta da qualsiasi posizione in cui è memorizzata e quindi conservata in memoria.

Yeah, it could be based on personal taste. But performance results and future maintenance can say otherwise.

La manutenzione riguarda il codice migliore e veramente è importante.

E ciò che è meglio dipende da come saranno usate quelle stringhe e quanto spesso dovranno cambiare:

• Per gli URL di servizi, è una buona idea tenerli in un file di proprietà separato (o JSON, YML, non importa molto anche se i commenti sono buoni), perché possono essere modificati senza ricostruire il applicazione, anche da parte di qualcuno senza esperienza di codifica.
• Per le stringhe che verranno visualizzate nell'interfaccia utente, anche un file separato è utile perché facilita le traduzioni, il controllo ortografico, il controllo della coerenza o cose simili.
• Un elenco fisso di stati dovrebbe essere sicuramente un enum, per la sicurezza dei tipi e per chiarire cosa è o non è uno stato possibile.
• Le stringhe che vengono realmente utilizzate solo all'interno del codice e che probabilmente cambieranno solo quando ci sono modifiche al codice NON dovrebbero essere inserite in un file di proprietà, ad esempio " soft coding "creerà solo problemi di manutenzione.

Usa un flatfile ogni volta che devi inviare dati di dimensioni fisse e molto altro. Se ci sono alcuni campi che variano, potresti considerare l'aggiunta di spazi per riempire il resto, ma alla fine della giornata, il file flat deve essere di lunghezza fissa.

Tuttavia forse hai a che fare anche con le descrizioni. Le descrizioni variano non solo, ma in molti casi non hai garanzie sulla lunghezza massima della descrizione. In questo caso, e ancora una volta, supponendo che tu abbia molte linee di questo, dovresti considerare l'uso di un file csv, dato che ti permette di definire le barriere sul campo. Solo non fare l'errore di assumere una descrizione non può contenere i caratteri usati come barriere usate nel csv. Scegli un personaggio che probabilmente non verrà utilizzato e sostituiscilo nei campi che utilizzi in csv per evitare l'arduo compito di analizzarlo a mano in seguito.

I file delle proprietà sono, a mio modesto avviso, un modo eccellente per salvare valori quando si hanno valori e chiavi. Sebbene diversamente da flatfile e csv, probabilmente non salveresti potenzialmente molte linee. Usa i file delle proprietà quando stai salvando le configurazioni, come sembra essere nel tuo caso. Funziona perfettamente con gli URL. In un file di proprietà, il primo carattere "=" è quello che divide la chiave dal valore (infatti se si desidera includere un carattere "=" come parte della chiave, si deve deve scappare ). Questo per dire che anche se il tuo URL contiene un segno di uguale, non avrai problemi.

Per strutturare le proprietà, potresti prendere in considerazione l'aggiunta di un prefisso, ad esempio:

[email protected]
config.password=iheartturkey

Puoi ulteriormente nidificare le proprietà aggiungendo ancora più prefissi per organizzare meglio.

Un trucco che ho imparato è usare \ character alla fine della riga per le proprietà multi-linea. Ho trovato che questo è infinitamente utile per salvare query SQL utilizzate nel mio programma, in quanto mi permette di cambiarlo in caso di problemi nella produzione, e sembra molto più pulito di una codifica hardcoding nel mio codice. Basta essere sicuri che il carattere \ è il carattere ultimo sulla linea, altrimenti viene interpretato come un semplice \ carattere e la tua riga successiva viene interpretata non come la continuazione ma come una propria chiave / linea di valore.

Se la struttura è cruciale, puoi prendere in considerazione l'utilizzo di un formato più appropriato per la strutturazione dei dati. Per questo, YAML e JSON sono entrambe le opzioni eccellenti. Se stai programmando in Java, il default tende ad usare i file delle proprietà, ma non ti senti obbligato a usarli.

Riguardo all'utilizzo delle enumerazioni per rappresentare i dati, questa è un'ottima idea se ti aspetti un elenco predefinito di valori possibili. Se colpisci dati che non ti aspetti, falliscono, e questa è una buona cosa ci crediate o no! Ti permette di garantire sin dall'inizio che i tuoi dati sono quelli che ti aspetti che siano.

Buona fortuna!

La mia esperienza mi dice che gli URI per servizi / apis dovrebbero essere in un file di configurazione, che consente la trasformazione della configurazione di build perché dev non parlerà con le stesse istanze del diritto di produzione?

Puoi avere proprietà sulla tua classe per renderle disponibili se necessario, ma i valori grezzi dovrebbero essere nella configurazione.

Per il gran numero di valori di tipo "stato" ... le "stringhe magiche" sono considerate pratiche sbagliate, ma nel mondo reale spesso esistono ancora ai fini dei motivi di integrazione legacy. Sarebbe meglio mantenere il codice non dipendente dalle stringhe magiche per evitare i rischi di errore di battitura. Potrebbe essere meglio avere un Enum dei valori possibili, ma anche un dizionario statico o una tabella di ricerca per incrociare il riferimento quando richiesto per quel motivo legacy / display? (La soluzione esatta dipenderà dal tuo contesto)