2010-05-04 20 views
7

Tengo una aplicación que necesita para almacenar datos. Actualmente, estoy usando la configuración de la aplicación integrada para hacerlo, pero solo me da dos opciones: ámbitos de aplicación y de usuario. Idealmente, quiero un ámbito "local" que permita que la aplicación se ejecute bajo otro usuario y aún así encuentre sus datos en lugar de volver a crearla para ese usuario. El alcance de la aplicación puede hacer esto, pero solo es de lectura. Los datos de la aplicación serán cambiados por el usuario. Está bien si solo el administrador puede hacer cambios en los datos.¿Dónde debo almacenar los datos de mi aplicación?

Como probablemente pueda adivinar, tengo una herramienta de administración que permite al usuario cambiar los datos y el corredor del servicio de Windows que lee los datos y hace algo con ellos. Sería genial si el operador de servicios de Windows accede a los datos creados por la herramienta de administración.

+0

¿Qué tipo de datos está almacenando? Preferencias de usuario, etc. o datos utilizados por la aplicación? – gooch

+0

Estoy almacenando datos increíblemente simples. Casi nunca habrá una situación en la que haya más de 10 objetos almacenados. Los datos son configuraciones de tareas (es decir, nombre, directorio, complemento para usar, etc.) que se ejecutarán en un servicio que existirá fuera de mi herramienta de administración. Es imperativo que el servicio pueda encontrar esta información. La configuración sería ideal, pero acceder desde el servicio parece que será difícil. ¿Cómo haría esto? –

Respuesta

7

Si los datos son muy , muy simple, y necesita que otras aplicaciones o usuarios (con los permisos apropiados) puedan leerlo, probablemente elegiría almacenarlo en un archivo XML o incluso en un archivo de texto sin formato dentro de la carpeta de datos de aplicación del usuario, que sería obtenido a través de Environment.GetFolderPath. Un ejemplo para guardar podría verse como:

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

Eso es - ¡la configuración se guardó! Puede cargarlos de nuevo con XDocument.Load.

+0

Gracias! Esto es genial. ¿Hay alguna forma de que esto funcione como settings.settings donde está fuertemente tipado? Me encantaría poder hacer algo como esto: Settings.Default.Tasks = TaskList; Settings.Default.Save(); –

+0

@joe: si eso es lo que desea, debe buscar en la clase 'XmlSerializer' y en el espacio de nombres' System.Xml.Serialization'. Puede usarlos para tomar una estructura de clase y serializarla "automáticamente" a/desde XML. Definitivamente * no puedes * hacer esta parte del objeto 'Configuración' real; si quieres usar 'Configuración', entonces usa' Configuración'. Si solo quieres que sea un objeto singleton como 'Properties.Settings.Default', entonces es posible, pero deberías implementar el patrón tú mismo. – Aaronaught

+0

Oh, por cierto. ¿Debo usar la carpeta CommonApplicationData en lugar de ApplicationData? La documentación dice "El directorio que sirve como un repositorio común para los datos específicos de la aplicación que utilizan todos los usuarios". –

0

Parece que desea almacenarlo en una base de datos, la pregunta es local o en una red o no. La respuesta también depende de qué tipo de datos está almacenando, cómo se distribuye su aplicación y otros factores.

Ah, y por cierto que podría ayudarle de mejor manera si se especifica su plataforma (preferiblemente con una etiqueta) - Silverlight, WPF, WinForms, asp.net, consola, etc.

+0

Lo siento, pensé que la etiqueta .NET era suficiente para especificar la plataforma. De todos modos, creo que una base de datos puede ser excesiva para mis necesidades de persistencia de datos. Esta va a ser una aplicación WPF. –

+0

Está bien, .NET puede cubrir todas las plataformas que enumeré, y las que no. –

Cuestiones relacionadas