Comment dois-je stocker des données en lecture seule à déployer avec mon application?

17

Je développe une application de bureau, et cette application nécessite des informations pour fonctionner, mais elle ne change aucune de ces informations (les données doivent être chargées à chaque exécution de l'application, mais les données ne sont jamais modifiées). Les données doivent être stockées sur le même ordinateur que l'application est en cours d'exécution (stockage côté client?).

Il est également préférable que l'utilisateur ne puisse pas facilement modifier ces informations (en supposant qu'il n'a pas beaucoup de connaissances informatiques).

Comment dois-je stocker ce type d'informations? Une base de données locale? XML envoyé avec l'application?

J'utilise WPF.

c# design data wpf appa yip yip
la source
2
Ce n'est pas une méta. Une méta est un site pour discuter des problèmes ou des préoccupations concernant les principaux sites où des questions sont posées.
jpmc26
1
Pourquoi ne voulez-vous pas que les utilisateurs modifient les informations? Est-ce un problème de sécurité ou quoi? Ces informations sont-elles censées être gardées secrètes pour l'utilisateur? Les raisons pourraient changer considérablement les réponses appropriées.
jpmc26
1
@ jpmc26 Eh bien, c'est une sorte de problème de sécurité, mais ce n'est pas grave. Le principal objectif de l'application est de communiquer via un port série avec un contrôleur de température (comme celui- ci), et le XML stockera des informations sur les adresses mémoire du contrôleur. Si l'utilisateur le modifie, cela peut causer des problèmes lors de l'exécution, je voudrais donc l'éviter. Mais c'est juste une préoccupation, comme je l'ai dit, pas un gros problème. ps: édité la question pour remplacer la méta pour SE . Merci.
appa yip yip
2
Si vous voulez une base de données locale, jetez un œil à SQLite. (Mais si les données sont suffisamment petites pour être chargées dans la RAM au démarrage, je préfère un fichier structuré simple comme json ou quelque chose de binaire)
CodesInChaos
1
"Si l'utilisateur le modifie, cela peut provoquer des problèmes lors de l'exécution, je voudrais donc l'éviter." ne ressemble pas du tout à un problème de sécurité. Un problème de sécurité est celui où vous avez une phrase secrète ou similaire dans le fichier. Mettez simplement les paramètres dans un fichier XML à côté de l'exécutable, et mettez un commentaire en haut qui dit "Ne touchez pas aux paramètres de ce fichier !!". Si l'utilisateur modifie des fichiers aléatoires dans votre répertoire d'installation, alors il mérite la cassure qu'il obtient.
Roger Lipscombe

Réponses:

14

Un fichier binaire serait la réponse évidente, mais cela dépend de la façon dont vous le chargez - vous pourriez aussi bien vous faciliter la vie si vous le pouvez.

XML pourrait être un bon choix car il existe des méthodes intégrées en C # pour lire ceci. Vous pouvez ajouter une somme de contrôle à vos données, de sorte que si l'utilisateur la modifie, la somme de contrôle ne correspondra plus (vous devez ajouter une vérification pour vous assurer que la somme de contrôle est valide)

Une base de données locale peut créer plus de problèmes car vous avez d'autres dépendances dont vous avez besoin pour pouvoir y accéder

Matt Wilko
la source
Je n'ai pas pensé à la somme de contrôle, c'est une très bonne idée. Donc, je génère une somme de contrôle et la stocke sur mon application, donc chaque fois que je désérialise le XML, je génère une nouvelle somme de contrôle et la compare avec la première?
appa yip yip
4
Si vous stockez la somme de contrôle dans l'application, vous ne permettrez jamais une configuration différente, vous pouvez donc aussi stocker les données de configuration sous forme de constantes d'application dans votre code. Si vous souhaitez pouvoir modifier la configuration à l'avenir, ajoutez la somme de contrôle (un meilleur terme serait un "hachage") en tant que champ du XML et utilisez-le pour vérifier que le XML n'a pas été falsifié. Bien sûr, un attaquant déterminé pourrait rechercher votre code, trouver votre logique de hachage et l'utiliser pour produire des fichiers XML valides, mais de toute façon les applications côté client sont toujours vulnérables aux attaquants déterminés.
SJuan76
4
Au lieu d'un fichier ou d'une base de données locale, un fichier de ressources intégré à l'assemblage serait préférable. Caché de l'utilisateur final, facilement gérable par le développeur tout en restant convivial. Si les performances sont un problème, la sérialisation binaire serait supérieure.
PTwr
@ SJuan76 Oui, le problème du hachage sur XML est qu'il peut être modifié si quelqu'un le désérialise. Quoi qu'il en soit, si le XML change (ce qui, je pense, ne se produira pas, mais qui sait), il ne changera que sur une nouvelle version de l'application, alors je suppose que je m'en tiendrai au hachage du code.
appa yip yip
2
@schmaedeck: Les fichiers de ressources sont littéralement des fichiers à l'intérieur du binaire exécutable. Icônes et chaînes et toutes les autres données constantes dont votre programme a besoin.
Mooing Duck
21

Si les données ne changent jamais et sont en lecture seule , placez-les simplement dans un fichier de code sous forme de liste de constantes.

public readonly string AppStartUpData = "MyAppNeedsThis";

Si ces données sont différentes par déploiement, un fichier externe est correct.

.Net est fourni avec des fichiers .config intégrés (App.Config). Il faut les utiliser car il existe des méthodes standard (intégrées au cadre) pour en lire les informations.

Utilisez les fichiers de configuration au cas où un paramètre devrait changer (ne dites jamais jamais) car ce ne sont que des fichiers texte (Xml). S'il y a des informations sensibles, on peut crypter un paramètre si nécessaire.

Jon Raynor
la source
J'ai pensé aux constantes / readonlys, le problème est qu'il y a beaucoup de données, donc je suppose que je vais suivre avec le fichier externe. Je vous remercie!
appa yip yip
5
@schmaedeck ... alors? Vous pouvez mettre ces définitions dans un fichier séparé et importer celui-ci. En fait, je crois que Qt fait ce genre de choses lors de la compilation des formulaires et des trucs, donc vous vous retrouvez avec des fichiers générés automatiquement qui ont des mégaoctets de données binaires (par exemple des images) dans certaines constantes, mais si c'est dans un fichier séparé, il n'y a rien de mal à cela .
Bakuriu
15

Vous pouvez toujours ajouter un fichier dans votre projet et définir son type de génération sur Embedded Resourceafin qu'il soit intégré directement dans l'application elle-même.

Alternativement, un fichier chiffré et placé dans un emplacement accessible.

TheLethalCoder
la source
1
C'est la meilleure réponse. Je voudrais voir quelques conseils supplémentaires sur la façon d'y parvenir. Vous bénéficiez des avantages d'un fichier de configuration potentiellement modifiable, mais vous pouvez le garder statique car il est incorporé dans votre assembly.
Gusdor
5

Si vous ne voulez pas que l'utilisateur regarde les données, vous devez les sérialiser dans un fichier de données binaires.

Seule l'application connaîtrait la longueur des morceaux à lire.

Je ne connais pas C # mais en Java vous créeriez le fichier comme ceci:

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

... et ils le lisent comme ceci:

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
la source
Je vais sûrement utiliser la sérialisation binaire. Merci beaucoup pour votre temps!
appa yip yip