Domanda

OK, quindi non voglio iniziare una guerra santa qui, ma stiamo cercando di consolidare il modo in cui gestiamo i file di configurazione delle nostre applicazioni e stiamo lottando per prendere una decisione sull'approccio migliore da adottare .Al momento, ogni applicazione che distribuiamo utilizza i propri file di configurazione ad hoc, siano essi file di proprietà (stile ini), XML o JSON (solo per uso interno al momento!).

La maggior parte del nostro codice al momento è Java, quindi lo stiamo esaminando Configurazione Apache Commons, ma lo abbiamo trovato piuttosto prolisso.Abbiamo anche guardato XMLBeans, ma sembra che si stia scherzando molto.Mi sento anche come se fossi stato spinto verso XML come formato, ma i miei clienti e colleghi sono preoccupati all'idea di provare qualcos'altro.Posso capirlo dal punto di vista del cliente, tutti hanno sentito parlare di XML, ma alla fine, non dovresti usare lo strumento giusto per il lavoro?

Quali formati e librerie utilizzano le persone nei sistemi di produzione al giorno d'oggi, qualcun altro sta cercando di evitarli imposta sulla parentesi angolare?

Modificare: deve davvero essere una soluzione multipiattaforma:Linux, Windows, Solaris ecc.e la scelta della libreria utilizzata per interfacciarsi con i file di configurazione è importante tanto quanto la scelta del formato.

È stato utile?

Soluzione

XMLXMLXMLXML.Stavamo parlando file di configurazione qui.Non è prevista alcuna "imposta sulle parentesi angolari" se non si serializzano oggetti in una situazione ad alto rendimento.

I file di configurazione devono essere leggibili e comprensibili dall'uomo, oltre che leggibili dalla macchina.XML è un buon compromesso tra i due.

Se nel tuo negozio ci sono persone che hanno paura della nuova tecnologia XML, mi dispiace per te.

Altri suggerimenti

YAML, per il semplice motivo che rende i file di configurazione molto più leggibili rispetto a XML.

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

Gli esempi sono stati presi da questa pagina: http://www.kuro5hin.org/story/2004/10/29/14225/062

Primo:Questo è un argomento di grande dibattito, non una rapida domanda e risposta.

Il mio preferito in questo momento è semplicemente includere Lua, Perché

  • Posso consentire cose come larghezza=altezza*(1+1/3)
  • Posso rendere disponibili funzioni personalizzate
  • Posso vietare qualunque altra cosa.(impossibile, ad esempio, in Python (compresi i sottaceti.))
  • Probabilmente vorrò comunque un linguaggio di scripting da qualche altra parte nel progetto.

Un'altra opzione, se ci sono molti dati, è usare sqlite3, perché hanno ragione a reclamare

  • Piccolo.
  • Veloce.
  • Affidabile.

Scegline tre qualsiasi.

A cui vorrei aggiungere:

  • i backup sono un gioco da ragazzi.(basta copiare il file db.)
  • più facile passare a un altro db, ODBC, qualunque cosa.(rispetto a fugly-file)

Ma ancora una volta, questo è un problema più grande.Una risposta "grande" a questa domanda probabilmente implica una sorta di matrice di funzionalità o elenco di situazioni come:

Quantità di dati o breve durata

  • Per grandi quantità di dati, potresti desiderare un'archiviazione efficiente, come un db.
  • Per brevi periodi (spesso), potresti desiderare qualcosa per cui non è necessario fare molta analisi, considera qualcosa che può essere mappato direttamente.

A cosa si riferisce la configurazione?

  • Ospite:
    • Mi piace YAML in /etc.È reimplementato in Windows?
  • Utente:
    • Consente agli utenti di modificare la configurazione con l'editor di testo?
    • Dovrebbe essere gestibile a livello centrale?Registro/gconf/db remoto?
    • Può l'utente averne diversi profili?
  • Progetto:
    • File nella directory del progetto?(Il controllo della versione di solito segue questo modello...)

Complessità

  • Ci sono solo pochi valori flat?Considera YAML.
  • I dati sono annidati o dipendenti in qualche modo?(È qui che la cosa diventa interessante.)
  • Potrebbe essere una caratteristica desiderabile consentire una qualche forma di scripting?
  • I modelli possono essere visualizzati come una sorta di file di configurazione.

Senza iniziare una nuova guerra santa, i sentimenti del post sulla “tassa sulla staffa angolare” sono un’area in cui io in gran parte in disaccordo con Jeff.Non c'è niente di sbagliato in XML, è ragionevolmente leggibile dall'uomo (tanto quanto lo sono i file YAML, JSON o INI) ma ricorda che il suo intento è quello di essere letto dalle macchine.La maggior parte delle combinazioni linguaggio/framework vengono fornite con un parser XML di qualche tipo gratuitamente che rende XML una scelta piuttosto buona.

Inoltre, se stai utilizzando un buon IDE come Visual Studio e se l'XML viene fornito con uno schema, puoi fornire lo schema a VS e magicamente ottieni intellisense (puoi ottenerne uno per NHibernate ad esempio).

In definitiva devi pensare a quanto spesso toccherai questi file una volta in produzione, probabilmente non così spesso.

Questo dice ancora tutto per me su XML e perché è ancora una scelta valida per i file di configurazione (da Tim Bray):

"Se vuoi fornire dati generici con cui il destinatario potrebbe voler fare cose impreviste, strane e folli, o se vuoi essere davvero paranoico e schizzinoso riguardo a i18n, o se quello che stai inviando è più simile a un documento che a una struttura, o se l'ordine dei dati è importante, o se i dati sono potenzialmente di lunga durata (come in, più di secondi), XML è la strada da percorrere.Mi sembra anche che la combinazione di XML e XPath raggiunga un punto debole per i formati di dati che devono essere estensibili;vale a dire, è abbastanza semplice scrivere codice di elaborazione XML che non fallisca in presenza di modifiche al formato del messaggio che non toccano la parte che ti interessa."

@Tipo

Ma la configurazione dell'applicazione non è sempre costituita solo da coppie chiave/valore.Guarda qualcosa come la configurazione di Tomcat per su quali porte è in ascolto.Ecco un esempio:

    <Connector port="80" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />


    <Connector port="8009" 
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

È possibile avere un numero qualsiasi di connettori.Se ne definisci di più nel file, esisteranno più connettori.Non si definisce più e non esiste più.Non esiste un buon modo (imho) per farlo con le vecchie coppie chiave/valore.

Se la configurazione della tua app è semplice, probabilmente va bene qualcosa di semplice come un file INI letto in un dizionario.Ma per qualcosa di più complesso come la configurazione del server, un file INI sarebbe un enorme problema da mantenere e qualcosa di più strutturale come XML o YAML sarebbe migliore.Tutto dipende dal problema impostato.

Stiamo utilizzando file di configurazione in stile ini.Noi usiamo il Nini libreria per gestirli.Nini lo rende molto facile da usare.Nini era originariamente per .NET ma è stato portato su altre piattaforme utilizzando Mono.

XML, JSON, INI.
Tutti hanno i loro punti di forza e di debolezza.
In un contesto applicativo, ritengo che il livello di astrazione sia la cosa importante.
Se puoi scegliere un modo per strutturare i dati che sia una buona via di mezzo tra la leggibilità umana e il modo in cui desideri accedere/astrarre i dati nel codice, sei a posto.

Usiamo principalmente XML dove lavoro, e non posso davvero credere che un file di configurazione caricato in una cache come oggetti quando viene letto per la prima volta o dopo che è stato scritto e poi separato dal resto del programma, sia davvero così tanto un successo né sulla CPU né sullo spazio su disco.
Ed è anche abbastanza leggibile, a patto di strutturare correttamente il file.

E tutte le lingue su tutte le piattaforme supportano XML attraverso alcune librerie piuttosto comuni.

@Herms

Ciò che intendevo veramente era attenersi al modo consigliato in cui il software dovrebbe memorizzare i valori di configurazione per una determinata piattaforma.

Ciò che spesso ottieni sono anche i modi consigliati in cui questi dovrebbero/possono essere modificati.Come un menu di configurazione in un programma o un pannello di configurazione in un'applicazione "preferenze di sistema" (per i software dei servizi di sistema, ad esempio).Non consentire agli utenti finali di modificarli direttamente tramite RegEdit o NotePad...

Perché?

  1. Gli utenti finali (= clienti) sono abituati alle loro piattaforme
  2. Il sistema per i backup può salvare meglio "configurazioni sicure" ecc

@ninesided

Di " scelta della biblioteca ", prova a collegare (collegamento statico) qualsiasi libreria selezionata per ridurre il rischio di entrare in una guerra di conflitto di versioni sui computer degli utenti finali.

Se il tuo file di configurazione è di sola scrittura, di sola lettura all'avvio e i tuoi dati sono un insieme di coppie nome-valore, la scelta migliore è quella che il tuo sviluppatore può far funzionare per prima.

Se i tuoi dati sono un po' più complicati, con annidamenti ecc., probabilmente ti troverai meglio con YAML, XML o SQLite.

Se sono necessari dati nidificati e/o la possibilità di interrogare i dati di configurazione dopo l'avvio, utilizzare XML o SQLite.Entrambi hanno linguaggi di query piuttosto buoni (XPATH e SQL) per dati strutturati/nidificati.

Se i dati di configurazione sono altamente normalizzati (ad es.5a forma normale) stai meglio con SQLite perché SQL è migliore per gestire dati altamente normalizzati.

Se hai intenzione di scrivere sul set di dati di configurazione durante il funzionamento del programma, allora è meglio utilizzare SQLite.Ad esempio, se si scaricano i dati di configurazione da un altro computer o se si basano le decisioni future sull'esecuzione del programma sui dati raccolti nell'esecuzione precedente del programma.SQLite implementa un motore di archiviazione dati molto robusto che è estremamente difficile da corrompere in caso di interruzioni di corrente o programmi bloccati in uno stato incoerente a causa di errori.I dati corruttibili comportano costi elevati di supporto sul campo e SQLite funzionerà molto meglio di qualsiasi soluzione sviluppata internamente o persino delle librerie più popolari attorno a XML o YAML.

Dai un'occhiata alla mia pagina per ulteriori informazioni su SQLite.

Per quanto ne so, il registro di Windows non è più il modo preferito per archiviare la configurazione se si utilizza .NET: la maggior parte delle applicazioni ora utilizza System.Configuration [1, 2].Poiché anche questo è basato su XML, sembra che tutto si stia muovendo nella direzione dell'utilizzo di XML per la configurazione.

Se vuoi rimanere multipiattaforma, direi che usare una sorta di file di testo sarebbe la strada migliore da percorrere.Per quanto riguarda la formattazione di detto file, potresti voler prendere in considerazione se un essere umano lo manipolerà o meno.XML sembra essere un po' più facile da manipolare manualmente rispetto ai file INI a causa della struttura visibile del file.

Per quanto riguarda l'imposta sulle parentesi angolari, non me ne preoccupo troppo spesso poiché le librerie XML si occupano di astrarla.L'unica volta che potrebbe essere presa in considerazione è se hai pochissimo spazio di archiviazione con cui lavorare e ogni byte conta.

[1] Spazio dei nomi System.Configuration - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Utilizzo dei file di configurazione dell'applicazione in .NET - http://www.developer.com/net/net/article.php/3396111

Stiamo utilizzando i file delle proprietà, semplicemente perché Java li supporta in modo nativo.Un paio di mesi fa ho visto che SpringSource Application Platform utilizza JSON per configurare il proprio server e sembra molto interessante.IO confrontato varie notazioni di configurazione e sono giunto alla conclusione che XML sembra essere la soluzione migliore al momento.Ha un buon supporto per gli strumenti ed è piuttosto indipendente dalla piattaforma.

Rif:il commento di epatel

Penso che la domanda originale riguardasse la configurazione dell'applicazione che un amministratore avrebbe fatto, non solo la memorizzazione delle preferenze dell'utente.I suggerimenti che hai fornito sembrano più per le preferenze dell'utente che per la configurazione dell'applicazione e di solito non sono qualcosa con cui l'utente si occuperebbe mai direttamente (l'app dovrebbe fornire le opzioni di configurazione nell'interfaccia utente e quindi aggiornare i file).Spero davvero che non costringeresti mai l'utente a visualizzare/modificare il registro.:)

Per quanto riguarda la domanda vera e propria, direi che XML probabilmente va bene, dato che molte persone saranno abituate a usarlo per la configurazione.Finché si organizzano i valori di configurazione in modo facile da usare, la "tassa sulle parentesi angolari" non dovrebbe essere poi così grave.

Forse un po' tangente qui, ma la mia opinione è che il file di configurazione dovrebbe essere letto in un dizionario dei valori chiave/tabella hash al primo avvio dell'app e da quel momento in poi sempre accessibile tramite questo oggetto per la velocità.In genere la tabella chiave/valore inizia come da stringa a stringa, ma le funzioni di supporto nell'oggetto eseguono operazioni come DateTime GetConfigDate(chiave stringa) ecc...

Penso che l'unica cosa importante sia scegliere il formato che preferisci e poter navigare velocemente.XML e JSON sono entrambi ottimi formati per le configurazioni e sono ampiamente supportati: l'implementazione tecnica non è il nocciolo del problema, credo.Riguarda al 100% ciò che ti semplifica il compito di gestire i file di configurazione.

Ho iniziato a utilizzare JSON perché lo utilizzo parecchio come formato di trasporto dei dati e i serializzatori ne facilitano il caricamento in qualsiasi framework di sviluppo.Trovo che JSON sia più facile da leggere rispetto a XML, il che rende molto più semplice per me la gestione di più servizi, ciascuno dei quali utilizza un file di configurazione che viene modificato abbastanza frequentemente!

Su quale piattaforma stai lavorando?Consiglierei di provare a utilizzare il metodo preferito/comune per questo.

  1. MacOSX - plist
  2. Win32 - Registro di sistema (o ce n'è uno nuovo qui, da tempo che lo sviluppo)
  3. Linux/Unix - ~/.apprc (forse nome-valore)
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top