Come devo archiviare i dati di sola lettura da distribuire con la mia applicazione?

17

Sto sviluppando un'applicazione desktop e questa applicazione richiede alcune informazioni per essere eseguita, ma non cambia nessuna di queste informazioni (i dati devono essere caricati su ogni esecuzione dell'app, ma i dati non vengono mai modificati). I dati devono essere archiviati sullo stesso computer in cui l'app è in esecuzione (archiviazione lato client?).

È anche meglio se l'utente non può modificare facilmente queste informazioni (supponiamo che non abbiano molta conoscenza dell'IT).

Come devo conservare questo tipo di informazioni? Un database locale? XML inviato con l'applicazione?

Sto usando WPF.

c# design data wpf

— appa yip yip
fonte

2

Questo non è un meta. Un meta è un sito per discutere problemi o preoccupazioni sui siti principali in cui vengono poste le domande.

— jpmc26,

1

Perché non vuoi che gli utenti cambino le informazioni? È un problema di sicurezza o cosa? Queste informazioni dovrebbero essere tenute segrete all'utente? Le ragioni potrebbero cambiare notevolmente le risposte appropriate.

— jpmc26,

1

@ jpmc26 Beh, è una specie di problema di sicurezza, ma non è un grosso problema. L'obiettivo principale dell'applicazione è comunicare attraverso una porta seriale con un controller di temperatura (come questo ) e l'XML memorizzerà alcune informazioni sugli indirizzi di memoria del controller. Se l'utente lo modifica, potrebbe causare problemi durante l'esecuzione, quindi vorrei evitarlo. Ma è solo una preoccupazione, come ho detto, non un grosso problema. ps: modificata la domanda per sostituire meta per SE . Grazie.

— appa yip yip,

2

Se vuoi un database locale, dai un'occhiata a SQLite. (Ma se i dati sono abbastanza piccoli da caricare nella RAM all'avvio, preferisco un semplice file strutturato come json o qualcosa di binario)

— CodesInChaos

1

"Se l'utente lo modifica, potrebbe causare problemi durante l'esecuzione, quindi vorrei evitarlo." non sembra affatto un problema di sicurezza. Un problema di sicurezza è quello in cui hai una passphrase o simile nel file. Basta inserire le impostazioni in un file XML accanto all'eseguibile e inserire un commento in alto che dice "Non toccare le impostazioni in questo file !!". Se l'utente modifica i file casuali nella directory di installazione, allora meritano qualsiasi malfunzionamento.

— Roger Lipscombe,

14

Un file binario sarebbe la risposta ovvia, ma dipende da come lo stai caricando: potresti anche semplificarti la vita se puoi.

XML potrebbe essere una buona scelta in quanto ci sono metodi integrati in C # per leggere questo. È possibile aggiungere un checksum ai dati, in modo che se l'utente lo modifica, il checksum non corrisponderà più (è necessario aggiungere un controllo per assicurarsi che il checksum sia valido)

Un db locale potrebbe creare più problemi perché hai altre dipendenze di cui hai bisogno per accedervi

— Matt Wilko
fonte

Non ho pensato al checksum, è davvero una bella idea. Quindi genera un checksum e lo memorizzo nella mia applicazione, quindi ogni volta che non serializzo l'XML, creo un nuovo checksum e lo confronto con il primo?

— appa yip yip,

4

Se memorizzi il checksum nell'applicazione, non ti consentirai mai una configurazione diversa, quindi puoi anche memorizzare i dati di configurazione come costanti dell'applicazione nel tuo codice. Se si desidera poter modificare la configurazione in futuro, aggiungere il checksum (un termine migliore sarebbe un "hash") come campo dell'XML e utilizzarlo per verificare che l'XML non sia stato manomesso. Ovviamente, un determinato aggressore può ricercare il tuo codice, trovare la tua logica di hash e usarlo per produrre file XML validi, ma comunque le applicazioni lato client sono sempre vulnerabili a determinati aggressori.

— SJuan76,

4

Invece di file o db locale, il file di risorse incorporato nell'assembly sarebbe migliore. Nascosto all'utente finale, facilmente gestibile dallo sviluppatore ma ancora user-friendly. Se le prestazioni sono un problema, la serializzazione binaria sarebbe superiore.

— PTwr,

@ SJuan76 Sì, il problema dell'hash su XML è che può essere modificato se qualcuno lo serializza. Ad ogni modo, se l'XML cambia (cosa che penso non accadrà, ma chi lo sa) cambierà solo su una nuova versione dell'app, quindi suppongo che continuerò con l'hash sul codice.

— appa yip yip,

2

@schmaedeck: i file di risorse sono letteralmente file all'interno del file binario eseguibile. Icone e stringhe e qualsiasi altro dato costante di cui il tuo programma ha bisogno.

— Mooing Duck,

21

Se i dati non cambiano mai e sono di sola lettura , inseriscili in un file di codice come elenco di costanti.

public readonly string AppStartUpData = "MyAppNeedsThis";

Se questi dati sono diversi per distribuzione, un file esterno va bene.

.Net viene fornito con i file .config integrati (App.Config). Si dovrebbero usare quelli in quanto esistono modi standard (integrati nel framework) per leggere le informazioni da essi.

Utilizzare i file di configurazione nel caso in cui un'impostazione debba cambiare (mai dire mai) in quanto sono solo file di testo (Xml). Se sono presenti informazioni riservate, è possibile crittografare un'impostazione se necessario.

— Jon Raynor
fonte

Ho pensato alle costanti / readonlys, il problema è che ci sono molti dati, quindi immagino che seguirò il file esterno. Grazie!

— appa yip yip,

5

@schmaedeck ... so? È possibile inserire tali definizioni in un file separato e importare quella. In effetti credo che Qt faccia questo genere di cose quando si compilano moduli e cose così si finisce con file generati automaticamente che hanno megabyte di dati binari (ad esempio immagini) in alcune costanti, ma se si trova in un file separato non c'è nulla di sbagliato in questo .

— Bakuriu,

15

Puoi sempre aggiungere un file nel tuo progetto e impostarne il tipo di build in Embedded Resourcemodo che sia incorporato direttamente nell'applicazione stessa.

In alternativa, un file crittografato e collocato in una posizione accessibile.

— TheLethalCoder
fonte

1

Questa è la risposta migliore Vorrei vedere qualche consiglio in più su come raggiungerlo. Ottieni i vantaggi di un file di configurazione potenzialmente modificabile, ma puoi mantenerlo statico poiché è incorporato nel tuo assembly.

— Gusdor,

5

Se non si desidera che l'utente dia una sbirciatina ai dati, è necessario serializzarli in un file di dati binari.

Solo l'app potrebbe conoscere la lunghezza dei blocchi da leggere da essa.

Non conosco C # ma in Java creeresti il file in questo modo:

FileOutputStream fos = new FileOutputStream(file);      
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(var1);
oos.writeObject(var2);
oos.writeObject(var3);
oos.writeObject(var4);

... e loro lo leggono così:

FileInputStream fis = new FileInputStream(file);
ObjectInputStream ois = new ObjectInputStream(fis);
Object o[] = new Object[4];
o[0] = ois.readObject();
o[1] = ois.readObject();
o[2] = ois.readObject();
o[3] = ois.readObject();

— Tulains Córdova
fonte

Userò sicuramente la serializzazione binaria. Grazie mille per il vostro tempo!

— appa yip yip,