Esiste un motivo pratico per non utilizzare un'impostazione ".NET" per archiviare dati che non sono un'impostazione?

Question

Esiste un motivo pratico per non utilizzare un'impostazione ".NET" per archiviare dati che non sono un'impostazione?

#1 da (2 voti)
#2 da (1 voti)

7

Le applicazioni .NET sviluppate utilizzando Visual Studio hanno un modo semplice per archiviare e ripristinare le impostazioni dell'utente. Puoi aggiungere il valore predefinito di un'impostazione in una classe speciale e avere accesso in lettura / scrittura ad esso in fase di esecuzione attraverso Properties.Settings.Default.SettingName .

Alcune applicazioni hanno l'uso per i valori da ricordare tra le sessioni, che dovranno essere memorizzate altrove rispetto alla memoria. Una possibilità sarebbe quella di creare un file di un formato specifico (XML, JSON, ini o qualcos'altro) nella directory dei dati dell'utente e usarlo per tali valori.
Le "impostazioni" sopra descritte sono essenzialmente tali file, ma i valori che devono essere ricordati potrebbero non essere tecnicamente impostazioni. Un esempio è il timestamp dell'ultima volta in cui è stata eseguita una determinata funzione.

Si potrebbe discutere contro la memorizzazione di tale valore in Properties.Settings in quanto non è un'impostazione (cioè la preferenza dell'utente) e quindi il nome dello spazio dei nomi potrebbe causare confusione.
Esiste, tuttavia, un motivo pratico per non utilizzare Properties.Settings per memorizzare tale valore?

.net persistence settings

posta George T 08.06.2016 - 15:38

fonte

2 risposte

Leggi altre domande sui tag .net persistence settings

I sottotipi di funzioni di livello inferiore-aritmetico sono quelli di livello più alto? Come organizzare il lavoro per un team che fornisce 3 prodotti connessi ma distinti e resta agile

score 2 · Answer 1

Hai scritto

Some applications have use for values to be remembered between sessions

bene, è vero ogni volta che devi persistere dati

would be to create a file of a specific format (XML, JSON, ini, or something else) in the user's data directory and use it for such values. [...] One example is the timestamp of the last time a certain function was performed.

Quindi stai parlando di dati che devono essere persistenti per utente (forse anche per macchina), e dove non è "mission critical" se vengono persi a causa di un backup mancante. Questo è IMHO esattamente il caso d'uso per Properties.Settings

the values that need to be remembered might not technically be settings.

Ma perché no? Perché associ qualcosa di diverso con quel termine? Non sarei così esigente riguardo al termine - solo perché Microsoft ha scelto il nome Settings per quella classe, e non ha chiamato la classe SettingsAndOtherUserPersistentData non dovrebbe impedirti di usare il meccanismo per il tuo scopo, a patto che si adatti lo scenario che ho scansionato sopra.

score 1 · Answer 2

Proprietà. Le impostazioni vengono memorizzate per l'utente sulla macchina. Se si desidera che le impostazioni siano comuni a tutti gli utenti e / oa tutte le macchine, questo metodo non funzionerebbe. Potresti anche voler avere parametri di input per l'applicazione che guidino il suo comportamento piuttosto che le preferenze, e avere diversi set di essi pronti per essere usati in diversi ambienti. Per questo, Properties.Settings non sarebbe corretto o utilizzabile in quanto vi è un solo set nascosto che non può essere modificato esternamente in modo facile e ovvio (non è possibile avviare l'applicazione istruendolo per utilizzare un particolare set). È comunque possibile caricare i parametri di input da Properties.Settings una volta che l'applicazione è attiva.

Proprietà.Impostazioni è un modo rapido per conservare alcune cose, ma presto cadrà a pezzi a mano a mano che la tua applicazione aumenterà a causa della mancanza di flessibilità e di indeterminatezza riguardo allo scopo dei dati memorizzati. Si desidera separare l'input dalle preferenze personali dalle preferenze amministrative dalla configurazione dalle impostazioni dell'ambiente a qualsiasi altra applicazione del software. E ciascuno potrebbe dover essere gestito separatamente da persone diverse e recuperato da diverse fonti (database, registro, documento xml, variabili d'ambiente).