2010-05-04 21 views
7

Ho un'applicazione che deve memorizzare i dati. Attualmente, sto usando le impostazioni dell'applicazione incorporate per farlo, ma mi dà solo due possibilità: l'ambito dell'applicazione e quello dell'utente. Idealmente, desidero un ambito "locale" che consenta all'applicazione di funzionare con un altro utente e di trovare comunque i suoi dati piuttosto che ricrearli per quell'utente. L'ambito dell'applicazione può farlo, ma è di sola lettura. I dati dell'applicazione verranno modificati dall'utente. Va bene se solo l'amministratore può apportare modifiche ai dati.Dove devo archiviare i miei dati dell'applicazione?

Come probabilmente si può intuire, ho uno strumento di amministrazione che consente all'utente di modificare i dati e il gestore di servizi Windows che legge i dati e fa qualcosa con esso. Sarebbe bello se il runner del servizio Windows accedesse ai dati creati dallo strumento di amministrazione.

+0

Che tipo di dati stai memorizzando? Preferenze dell'utente, ecc. O dati utilizzati dall'applicazione? – gooch

+0

Sto memorizzando dati incredibilmente semplici. Non ci sarà quasi mai una situazione in cui sono memorizzati più di 10 oggetti. I dati sono impostazioni delle attività (ad esempio nome, directory, plug-in da utilizzare, ecc.) Che verranno eseguite in un servizio che esisterà al di fuori del mio strumento di amministrazione. È fondamentale che il servizio possa trovare queste informazioni. Le impostazioni sarebbero ideali, ma accedervi dal servizio sembra difficile. Come lo farei? –

risposta

7

Se i dati molto è , molto semplice, e hai bisogno che sia leggibile da altre applicazioni o utenti (con le autorizzazioni appropriate), probabilmente sceglierei di memorizzarlo in un file XML o anche in un file di testo normale all'interno della cartella Dati dell'applicazione dell'utente, che sarebbe ottenuto tramite Environment.GetFolderPath. Un esempio per il salvataggio potrebbe essere:

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); 

Questo è tutto: impostazioni salvate! Puoi caricarli di nuovo con XDocument.Load.

+0

Grazie! È grandioso Esiste comunque la possibilità di eseguire questo lavoro come settings.settings in cui è fortemente digitato? Mi piacerebbe essere in grado di fare qualcosa di simile a questo: Settings.Default.Tasks = TaskList; Settings.Default.Save(); –

+0

@joe: se è ciò che si desidera, è necessario esaminare la classe 'XmlSerializer' e lo spazio dei nomi' System.Xml.Serialization'. Puoi usarli per prendere una struttura di classe e serializzarli "automaticamente" su/da XML. Sicuramente * non puoi * rendere questa parte dell'attuale oggetto 'Settings'; se vuoi usare le "Impostazioni", usa "Impostazioni". Se vuoi solo che sia un oggetto singleton come 'Properties.Settings.Default', allora è possibile, ma dovresti implementare il pattern tu stesso. – Aaronaught

+0

Oh btw. Dovrei usare la cartella CommonApplicationData invece di ApplicationData? La documentazione dice "La directory che funge da repository comune per dati specifici dell'applicazione che viene utilizzata da tutti gli utenti." –

0

Suoni come se si desidera archiviarli in un database, la domanda è locale o in rete oppure no. La risposta dipende anche dal tipo di dati che stai memorizzando, da come viene distribuita la tua app e da altri fattori.

Ah, e BTW abbiamo potuto aiutare meglio se si specifica la piattaforma (preferibilmente con un tag) - Silverlight, WPF, WinForms, asp.net, console, ecc

+0

Siamo spiacenti, pensavo che il tag .NET fosse sufficiente per specificare la piattaforma. Ad ogni modo, penso che un database possa essere eccessivo per le mie esigenze di persistenza dei dati. Questa sarà un'applicazione WPF. –

+0

OK, .NET può coprire tutte le piattaforme che ho elencato e quelle che non ho. –

Problemi correlati