2009-05-19 4 views
20

Quando il registro di Windows deve essere utilizzato per lo stato per utente e quando dovremmo usare il filesystem, in particolare la cartella AppData dell'utente? (ad es. C: \ Users \ USERNAME \ AppData). Da dove arriva lo storage isolato?Come decidere dove memorizzare lo stato per utente? Registry? AppData? Storage isolato?

C'è una regola piuttosto solida, o è solo una cosa fuzzy, come "usa il registro finché non diventa troppi dati da memorizzare nel registro". o "usa quello che hai voglia di usare".

Ci sono requisiti del logo di Windows che influiscono sulla decisione?

Se utilizzo la directory AppData, come scegliere tra Local, Roaming e LocalLow?

Edit: Ho appena notato queste domande simili:

Riassumerò le risposte.

risposta

11

Se si dispone di un numero limitato di coppie chiave/valore ei valori non sono grandi il Registro di sistema è grande - e non si cura sulla distribuzione xcopy - quindi utilizzare il Registro di sistema (So che questo non è esatto, ma di solito è ovvio quando si lavora con il registro diventa un dolore).

Se si desidera la distribuzione di xcopy, i dati devono trovarsi nella stessa cartella del programma, ovviamente - ma il programma può trovarsi da qualche parte nella cartella AppData, non deve trovarsi in "file di programma".

Utilizzare lo spazio di archiviazione isolato solo quando è necessario o necessario utilizzarlo, ad esempio ClickOnce.

In caso contrario, utilizzare AppData \ Roaming, utilizzare Local o LocalLow solo se si dispone di una buona ragione.

EDIT: Qui è la differenza tra Roaming, LocalLow locale e:

Windows ha una caratteristica poco conosciuto chiamato "profili", l'idea generale è che in un ambiente aziendale con questa funzione attivata qualsiasi utente può utilizzare qualsiasi computer.

Quando un utente accede alle sue impostazioni private viene scaricato dal server e quando si disconnette le sue impostazioni vengono caricate di nuovo sul server (il processo effettivo è più complicato, ovviamente).

I file nella cartella "Roaming" dell'utente in Vista o "Dati applicazioni" in XP si spostano con l'utente, quindi tutte le impostazioni e i dati devono essere memorizzati lì.

I file in "Locale" e "LocalLow" in Vista e "Impostazioni locali" in XP no, quindi è un buon posto per i file temporanei, cose legate al computer specifico o dati che possono essere ricalcolati.

In Vista, come parte delle nuove funzionalità di sicurezza che tutti conosciamo e amiamo, è possibile avere programmi in esecuzione in "modalità di bassa integrità" (ad esempio IE in modalità protetta), quei programmi sono in esecuzione con privilegi ridotti e possono t accedere ai file nel profilo dell'utente - ad eccezione dei file nella cartella "LocalLow".

Quindi, in conclusione, i file memorizzati in "LocalLow" sono intrinsecamente insicuri e i file in "Locale"/"Impostazioni locali" potrebbero non essere disponibili in alcune grandi aziende, quindi a meno che non si abbia una buona ragione e sappia esattamente cosa stanno facendo andare con "Roaming"/"Dati dell'applicazione".

+0

Potresti elaborare su AppData \ Roaming vs. Local - perché è meglio? –

+1

Sergey, ho aggiunto le informazioni richieste, spero che lo trovi utile – Nir

+0

% APPDATA% punti alla cartella Roaming. Ce n'è uno che punta alla cartella locale? (Diverso da% APPDATA% \ .. \ local) – Vaccano

4

Si potrebbe prendere in considerazione Isolated Storage.

+0

ok, grazie. Buona informazione Storage isolato utilizza una sottodirectory in AppData per la posizione effettiva. È anche ben isolato. Quindi immagino si tratti di una decisione basata sulla dimensione. Se richiederebbe più di alcune voci di registro, quindi utilizzare lo spazio di archiviazione isolato? – Cheeso

1

Non so se esiste una regola fissa, ma una cosa da considerare è che il registro viene gestito - è più sicuro per le operazioni di lettura/scrittura simultanee. Pertanto, se i dati dell'utente potrebbero essere scritti da più thread in fase di esecuzione (o se sono presenti più exe nel pacchetto del prodotto), prendere in considerazione l'utilizzo del registro.

Cronologia: Un motivo (come ho sentito dire) che MS è passato da file .ini al registro era precisamente per provare a gestire il problema di accesso simultaneo.

. NET (sorta di) è tornato ai file .ini sotto forma di file .config xml, tuttavia questi file di configurazione non devono essere scritti in runtime (o almeno non se c'è una possibilità di concorrere scrittori/lettori).

Maggiori informazioni: http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx

+0

il file di configurazione dell'utente è progettato per essere modificato in fase di runtime. –