net - error en la inicialización del sistema de configuración c#

Dónde almacenar la información de configuración

Question

Tengo una aplicación de consola que estoy reconstruyendo de C a C #. Esta aplicación debe ser compatible con el método heredado de almacenar información como parámetros de una línea de comandos y parámetros de un archivo (llamados parámetros del sistema) que personalizan cada ejecución. El archivo de parámetros del sistema está en texto sin formato con una clave simple: estructura de valores.

Mis preguntas son:

• ¿Debo combinar estos diferentes parámetros en un único objeto de configuración?
• ¿Cómo llamaría a este objeto de configuración desde el código para almacenar parámetros?
• ¿Cómo podría llamar a este objeto de configuración desde el código para recuperar los parámetros?
  • ¿Debería este objeto ser fuertemente tipado?
• Necesitaré acceso a esta estructura desde muchos lugares diferentes en el código, ¿cuál es la forma más elegante de recuperar los valores en el objeto sin pasar el objeto por sí mismo por todas partes?

Tengo la sensación de que debe ser un objeto único con fuerte tipado y que debe ser un objeto instanciado que se recupera de un repositorio con un método de recuperación estático; sin embargo, realmente quiero la validación de este método.

Gracias por adelantado

Answer 1

Me parece que cada vez que tengo que lidiar con un sistema heredado, seguir el viejo formato casi siempre funciona mejor. Muchas veces hay otras personas que usan los formatos heredados para otras tareas (como la automatización de la aplicación, por ejemplo), por lo que si recodifica la forma en que la aplicación maneja las entradas, puede romper otros sistemas.

Por otro lado, si confías en que conoces a todas las personas que usan el sistema y te dicen que no les importa si cambias este tipo de cosas, probablemente movería todo a XML. Además de todas las características agradables de XML desde el punto de vista de una aplicación (como estar en ASCII por lo que es fácilmente modificado por humanos, ser autodocumentado, etc.), XML también ahorra tiempo, ya que no tiene para escribir tu propia E / S o analizador. Ya hay una gran variedad de bibliotecas, especialmente en .NET 3.0 / 3.5, que funcionan muy bien. (A medida que se mude a C #, supongo que ya está pensando en estas líneas :)

Por lo tanto, en última instancia, debe basar su decisión en el costo de implementación: si reduce el costo de implementación al cambiar a XML o similar, asegúrese de no aumentar el costo de implementación de otras personas para pasar a su nuevo marco de aplicación.

¡Buena suerte!

Answer 2

XmlDocument: puede generar una definición de clase con XSD.exe

Answer 3

Me gusta usar Settings . Se pueden generar automáticamente creando un archivo de configuración usando el cuadro de diálogo Agregar nuevo archivo o agregando un archivo de configuración predeterminado desde Propiedades del proyecto. Cada configuración puede estar en el ámbito de Usuario o Aplicación, que controla si el usuario puede cambiarlos o si están restringidos a sus valores predeterminados. Se guardan fácilmente con el método Save() y se cargan automáticamente en la propiedad Default estática.

Esta clase parece ser para aplicaciones o configuraciones basadas en el usuario. Estoy buscando configuraciones por ejecución. ¿Todavía recomendaría usar esta clase en ese caso? - x97mdr

Sí. Si tiene configuraciones basadas en usuario / aplicación y configuraciones por ejecución, debe usar dos clases diferentes: la configuración normal (guardada) y la configuración por ejecución. Siempre que no guarde la configuración por ejecución, debe estar seguro y la configuración es bastante fácil de usar. Estas son configuraciones estáticas sin embargo. Si la misma ejecución de la aplicación necesita varias instancias, este es el enfoque equivocado.

Answer 4

Yo usaría un solo objeto de configuración como el siguiente:

using System;
using System.IO;
using System.Reflection;
public sealed class Setting {
public static int FrameMax { get; set; }
public static string VideoDir { get; set; }
static readonly string SETTINGS = "Settings.ini";
static readonly Setting instance = new Setting();
Setting() {}
static Setting() {
string property = "";
string[] settings = File.ReadAllLines(SETTINGS);
foreach (string s in settings)
try {
string[] split = s.Split(new char[] { '':'' }, 2);
if (split.Length != 2)
continue;
property = split[0].Trim();
string value = split[1].Trim();
PropertyInfo propInfo = instance.GetType().GetProperty(property);
switch (propInfo.PropertyType.Name) {
case "Int32":
propInfo.SetValue(null, Convert.ToInt32(value), null);
break;
case "String":
propInfo.SetValue(null, value, null);
break;
}
} catch {
throw new Exception("Invalid setting ''" + property + "''");
}
}
}

Como se trata de un singleton , creará una única instancia de sí mismo la primera vez que se haga referencia a una propiedad public static desde el objeto Setting .

Cuando se crea el objeto, se lee desde el archivo Settings.ini . El archivo de configuración es un archivo de texto sin formato con una key : value simple key : value estructura de key : value que podría verse así:

FrameMax : 12
VideoDir : C:/Videos/Best

El objeto utiliza la reflexión para descubrir cada propiedad y almacenar su valor inicial. En este ejemplo, se han definido dos propiedades:

 public static int FrameMax { get; set; }
public static string VideoDir { get; set; }

El código tal como está escrito maneja los tipos Int32 y String . Al agregar declaraciones de case adicionales a la instrucción switch , puede agregar fácilmente soporte para tipos como Float y Decimal .

Para cambiar una configuración, usaría algo como:

Setting.FrameMax = 5;

Para recuperar una configuración, usaría algo como:

if (Setting.FrameMax > 10) ...

Notarás que todas las propiedades están fuertemente tipadas. Además, no tiene que pasar el objeto de Setting , ya que todas las propiedades de Setting son static y siempre están disponibles en todas partes.

Espero que esta idea sea útil.