file INI o registro o file personali?

18

Voglio salvare la configurazione del mio progetto che include

  1. Dimensione dello schermo
  2. Posizione dello schermo
  3. Percorsi cartella
  4. Impostazioni utenti e così via.

Le posizioni standard in cui è possibile salvare sono valori di configurazione:

  1. Registro
  2. File INI
  3. File personali (come * .cfg)

Come scegli tra questi posti? Inoltre, ci sono vantaggi e svantaggi nell'usarli?

    
posta Shirish11 13.04.2012 - 08:50
fonte

6 risposte

20

Also are there any pros and cons of using any of them?

Registro:

  • + Relativamente standard nell'ambiente Windows.
  • + Generalmente un buon supporto da parte degli installer, ecc.
  • - API specifica per piattaforma, se si desidera eseguire il porting dell'applicazione.
  • - Non particolarmente leggibile.

File INI:

  • + Formato semplice.
  • + Portatile.
  • + Human readable.
  • - Può essere difficile archiviare informazioni più complesse (ad esempio, qualsiasi elemento annidato a più di due livelli di profondità).
  • ? Potrebbe scrivere il parser (anche se non è difficile) o usare una libreria esterna come SimpleIni (grazie a Jonathan Merlet per il commento).

File XML (suppongo che questa sia l'opzione .cfg):

  • + Un formato standard.
  • + Portatile.
  • + Supporta strutture profondamente annidate.
  • - Non particolarmente leggibile.

Personalmente, per le applicazioni di Windows tendo ad usare C # e con un file personale per l'utente, memorizzato come XML. Lo faccio in genere perché la leggibilità umana non è in genere una priorità nei tipi di applicazioni che scrivo (e l'applicazione dovrebbe avere un editor di configurazione, in ogni caso) e nel . NET ambiente, è molto facile lavorare con XML. Molto spesso finisco con un oggetto UserConfiguration che viene semplicemente serializzato da e verso un file di configurazione - quasi nessuno sviluppo (parsing, casting in giro) e la tua configurazione è pronta per l'uso in un ambiente strongmente tipizzato.

    
risposta data 13.04.2012 - 11:36
fonte
15

Vado con i file INI, sono l'opzione più umana:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

L'XML potrebbe essere una buona opzione, ma non può battere la semplicità e l'eleganza di INI:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

Gli INI sono anche molto ben compresi e indipendenti dalla piattaforma. Non ci sono probabilmente tanti strumenti disponibili per loro come per i file XML, perché, beh, chi ha bisogno di uno strumento specializzato per leggere e modificare un file INI?

    
risposta data 13.04.2012 - 09:02
fonte
6

La mia preferenza sono i file XML. Sono gerarchici, puoi piegarli alla tua volontà in quasi tutti i modi immaginabili, sono ben compresi, indipendenti dalla piattaforma e c'è una vasta gamma di software disponibili per leggerli e scriverli.

    
risposta data 13.04.2012 - 08:52
fonte
6

Per espandere il suggerimento di Jeff D' YAML , ecco una breve introduzione.

YAML è simile a JSON (infatti, JSON è un sottoinsieme di YAML dalla versione 1.2 dello standard YAML e può quindi essere analizzato con parser YAML in modo valido). A prima vista, la differenza principale è che YAML (per impostazione predefinita) utilizza la rientranza anziché il bracketing per mostrare la gerarchia. C'è anche una notevole mancanza di virgolette per le stringhe. Un rapido esempio da sopra:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

Vedi la pagina YAML di Wikipedia per esempi migliori. Il supporto per YAML esiste per la maggior parte delle lingue principali (per i dettagli vedere yaml.org ).

    
risposta data 16.04.2012 - 08:02
fonte
3

Hai dimenticato un'opzione: il Database. Questo è principalmente utilizzato in scenari in cui gli utenti accedono all'applicazione quando l'applicazione non può fare affidamento sull'utente Windows connesso. Questo è ad esempio quando la tua app è in esecuzione in una finestra in modalità kiosk.

    
risposta data 16.04.2012 - 11:59
fonte
1

La mia preferenza personale sono i file XML:

Nella maggior parte dei casi non mi aspetto che l'utente debba modificare le proprie impostazioni di configurazione in modo che il problema della leggibilità umana non sia un argomento in questo caso.

Se hanno bisogno di modificarli, puoi fornire uno strumento di modifica - questo impedisce all'utente di fare qualcosa di stupido con i dati. Se vogliono ripristinare le impostazioni predefinite, puoi semplicemente dire loro di cancellare il file x che la maggior parte degli utenti si troverà a proprio agio.

Tieni presente che devi ancora stare attento a disporre dell'autorizzazione per archiviare il tuo file poiché alcune posizioni non hanno accesso in scrittura per impostazione predefinita in Windows 7 ecc.

I file INI sono un modo standard per archiviare la configurazione e sono provati e testati, ma mi sembrano un po '"Windows 3.1"!

Probabilmente l'opzione migliore se vuoi che l'utente sia in grado di armeggiare con i propri dati

Direrei personalmente al registro. Per prima cosa non puoi garantire che l'utente disponga delle autorizzazioni necessarie per leggere / scrivere dove vuoi archiviare i tuoi dati.

Nei sistemi operativi più recenti in cui entra in gioco la virtualizzazione del registro questo può causare grande confusione perché non è possibile "vedere" le impostazioni virtualizzate - questo ci ha morso più di una volta dove abbiamo passato ore a cercare di capire perché qualcosa non funzionava .

    
risposta data 13.04.2012 - 13:16
fonte