Configurazione del tempo di compilazione: programmatico o basato su file?

Question

Configurazione del tempo di compilazione: programmatico o basato su file?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

5

Abbiamo bisogno di personalizzare un'applicazione desktop in fase di compilazione. Gli utenti non possono modificare la configurazione. Solo gli sviluppatori e i responsabili delle versioni possono farlo.

La configurazione è un po 'complessa. Ci sono più di 10 moduli. Ogni modulo necessita di configurazione inclusi valori, indicatori di capacità, ecc. Abbiamo 5 gruppi di configurazione chiamati profili.

Ora, sceglierò una delle due opzioni. Il primo è l'approccio programmatico. Possiamo creare interfacce di configurazione per ciascun modulo e implementarle per ciascun profilo. L'alternativa è quella di usare i file di configurazione. Mi piace l'approccio programmatico per la sua flessibilità (ad esempio, possiamo ereditare un profilo da un altro). Inoltre, fornisce il controllo del tempo di compilazione. Ma i file di configurazione (come gli XML) sono facili da mantenere e da capire.

Forse, un approccio misto sarà il migliore. Ma non sono sicuro di come farlo. Hai qualche idea?

Grazie.

release-management configuration

posta Q Q 28.04.2016 - 16:21

fonte

4 risposte

Leggi altre domande sui tag release-management configuration

Mantenere aggiornato un fork git permanente [chiuso] Memorizzazione dei dati OAuth2 in Mongo?

score 1 · Answer 1

Il grande vantaggio di un file di configurazione, che si tratti di xml, json, ini, è che separa i dati dal comportamento. Questo può aiutare a tenerlo leggibile. Puoi farlo anche con il codice; non sei obbligato a farlo.

Se preferisci mantenere i file di configurazione, un modo per soddisfare la tua esigenza di proteggere la tua configurazione sarebbe di compilare la tua configurazione in qualche modo. Questo potrebbe essere qualsiasi cosa, dall'offuscamento alla crittografia allo zipping e alla protezione tramite password. Nessuno sarà perfettamente sicuro; nessuno dei due è un codice, ma dovrebbe impedire all'utente casuale di manipolare le impostazioni.

La configurazione in codice può essere semplice, ma richiede disciplina. Per questo possono essere sfruttati modelli costruttivi o creativi. Se hai il tempo di scriverne uno, puoi arrivare fino alla creazione di un builder DSL (Domain Specific Language).

score 0 · Answer 2

Ho un'idea per un approccio misto. Potremmo generare classi di configurazione dai file di configurazione. Immagino un meccanismo del genere: ogni modulo ha uno schema xsd per la sua configurazione richiesta. Quando lo schema viene modificato, la classe di configurazione verrà rigenerata automaticamente. Quindi, le altre classi useranno la configurazione a livello di codice.

I profili avranno file di configurazione xml per ogni modulo. Gli XML possono essere convalidati contro gli XSD. Nell'applicazione principale, un gestore profili caricherà xml di configurazione e passerà loro i moduli. Quindi, la configurazione potrebbe essere mantenuta facilmente giocando con XML.

score 0 · Answer 3

Approccio di file di configurazione puro che consente l'ereditarietà:

Dato che stai cercando di avere una serie di configurazioni padre da cui puoi ereditare, potresti configurare un sistema di file di configurazione a due livelli? Avere un "master" e un file "specifico" e se il master e lo specifico definiscono lo stesso valore di configurazione, viene utilizzato il valore del file specifico.

Questa non è una nuova idea - pensa css, la configurazione principale di apache e .htaccess, e sono sicuro che anche molte altre tecnologie.

Una leggera variazione di ciò che si vede con i file di configurazione di git e qualsiasi file di configurazione bash è l'idea di "sourcing" di un altro file (incluso, come nell'ereditarietà) - All'inizio di un file, si indica che esso ne estende un altro, e quando il tuo file viene letto, l'istruzione "estendi tale e tale file" significa "smetti di leggere questo file, elabora tutti questi file e poi continua a leggere questo file".

Questo ti permette di avere un numero qualsiasi di livelli di ereditarietà.

score -1 · Answer 4

Ecco un altro approccio misto.

Vorrei chiedere cosa cambia spesso. Questi valori possono essere inseriti in un file excel o foglio di calcolo. Quel campo avrà etichette, unità e intervalli validi in esso per ogni valore modificabile.

Il codice spesso non modificato può andare in codice. Questo può essere utilizzato nelle classi ambientali. Le classi lasciano correre i casi d'uso, ma sono sufficienti per un ambiente in cui il sistema potrebbe essere inserito. Nuovi elementi necessari (qui è il presupposto del sistema). Quindi, i valori restituiti e i parametri vengono passati in metodi. La classe non dovrebbe avere if o loop.