2010-05-04 7 views
7

J'ai une application qui a besoin de stocker des données. Actuellement, j'utilise les paramètres d'application intégrés pour le faire, mais cela ne me donne que deux choix: l'étendue de l'application et de l'utilisateur. Idéalement, je veux une portée "locale" qui permette à l'application de s'exécuter sous un autre utilisateur et de toujours trouver ses données plutôt que de les recréer pour cet utilisateur. La portée de l'application peut le faire, mais elle est en lecture seule. Les données d'application seront modifiées par l'utilisateur. C'est OK si seulement l'administrateur est autorisé à apporter des modifications aux données.Où dois-je stocker mes données d'application?

Comme vous pouvez probablement le deviner, j'ai un outil d'administration qui permet à l'utilisateur de changer les données et le coureur de service Windows qui lit les données et fait quelque chose avec lui. Ce serait génial si le coureur du service Windows accède aux données créées par l'outil d'administration.

+0

Quel type de données stockez-vous? Préférences de l'utilisateur, etc. ou données utilisées par l'application? – gooch

+0

Je stocke des données incroyablement simples. Il n'y aura presque jamais de situation où plus de 10 objets sont stockés. Les données sont des paramètres de tâche (c'est-à-dire, nom, répertoire, plugin à utiliser, etc.) qui seront exécutés dans un service qui existera en dehors de mon outil d'administration. Il est impératif que le service puisse trouver cette information. Les paramètres seraient idéaux, mais l'accès à partir du service semble être difficile. Comment ferais-je cela? –

Répondre

7

Si les données sont très , très simple, et vous avez besoin qu'il soit lisible par d'autres applications ou utilisateurs (avec les autorisations appropriées), je choisirais probablement de le stocker dans un fichier XML ou même un fichier texte dans le dossier Application Data de l'utilisateur, qui serait obtenu via Environment.GetFolderPath. Un exemple d'enregistrement peut ressembler à ceci:

using System.IO; 
using System.Xml.Linq; 

string settingsDirectory = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 
if (!Directory.Exists(settingsDirectory)) 
    Directory.CreateDirectory(settingsDirectory); 
string fileName = "tasks.xml"; 
string settingsPath = Path.Combine(settingsDirectory, fileName); 
XDocument settingsDoc = new XDocument(
    new XElement("Tasks", 
     new XElement("Task", 
      new XElement("Name", "Make Breakfast"), 
      new XElement("Location", @"C:\Program Files\MyApp\Plugins"), 
      new XElement("FileName", "breakfast.dll")))); 
// ... etc. 
settingsDoc.Save(settingsPath); 

C'est tout - les paramètres sont sauvegardés! Vous pouvez les charger à nouveau avec XDocument.Load.

+0

Merci! C'est bien. Y at-il de toute façon pour faire ce travail comme settings.settings où il est fortement typé? J'aimerais pouvoir faire quelque chose comme ceci: Settings.Default.Tasks = TaskList; Settings.Default.Save(); –

+0

@joe: Si c'est ce que vous voulez, vous devriez regarder dans la classe 'XmlSerializer' et l'espace de noms' System.Xml.Serialization'. Vous pouvez les utiliser pour prendre une structure de classe et sérialiser "automatiquement" vers/depuis XML. Vous ne pouvez certainement * pas * faire cette partie de l'objet 'Settings' réel; Si vous voulez utiliser les 'Paramètres', utilisez les' Paramètres'. Si vous voulez juste que ce soit un objet singleton comme 'Properties.Settings.Default', alors c'est possible mais vous devrez implémenter le pattern vous-même. – Aaronaught

+0

Oh btw. Dois-je utiliser le dossier CommonApplicationData au lieu de ApplicationData? La documentation indique "Le répertoire qui sert de référentiel commun pour les données spécifiques à l'application utilisées par tous les utilisateurs." –

0

Semble que vous voulez le stocker dans une base de données, la question est locale ou sur un réseau ou non. La réponse dépend également du type de données que vous stockez, de la manière dont votre application est distribuée et d'autres facteurs.

Oh, et BTW nous pourrions vous aider à bien meilleur si vous spécifiez votre plate-forme (de préférence avec une étiquette) - silverlight, WPF, WinForms, asp.net, console, etc.

+0

Désolé, je pensais que la balise .NET était suffisante pour spécifier la plate-forme. Quoi qu'il en soit, je pense qu'une base de données peut être trop lourde pour mes besoins de persistance des données. Cela va être une application WPF. –

+0

son OK, .NET peut couvrir toutes les plates-formes que j'ai énumérées, et ceux que je n'ai pas. –

Questions connexes