¿Qué método de configuración prefieres en .net?¿Por qué?[cerrado]

StackOverflow https://stackoverflow.com/questions/117407

  •  02-07-2019
  •  | 
  •  

Pregunta

  • Puedes usar App.config;pero sólo admite pares clave/valor.
  • Puede utilizar la configuración .Net, secciones de configuración;pero puede ser realmente complejo.
  • Puede utilizar la serialización/deserialización Xml usted mismo;Tus clases, a tu manera.
  • Puedes utilizar algún otro método;¿Qué pueden ser?...

¿Cuál de estos u otros métodos (si los hay) prefieres?¿Por qué?

¿Fue útil?

Solución

Cuando los pares clave-valor no son suficientes, uso Secciones de configuración ya que no son complejas de usar (a menos que necesites una sección compleja):

Defina su sección personalizada:

        public class CustomSection : ConfigurationSection
        {
            [ConfigurationProperty("LastName", IsRequired = true,
            DefaultValue = "TEST")]
            public String LastName
            {
                get { return (String)base["LastName"]; }
                set { base["LastName"] = value; }
            }

            [ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
            "TEST")]
            public String FirstName
            {
                get { return (String)base["FirstName"]; }
                set { base["FirstName"] = value; }
            }

            public CustomSection()
            {

            }
        }

Cree su sección mediante programación (si aún no existe):

           // Create a custom section.
            static void CreateSection()
            {
                try
                {

                    CustomSection customSection;

                    // Get the current configuration file.
                    System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

                    // Create the section entry  
                    // in the <configSections> and the 
                    // related target section in <configuration>.
                    if (config.Sections["CustomSection"] == null)
                    {
                        customSection = new CustomSection();
                        config.Sections.Add("CustomSection", customSection);
                        customSection.SectionInformation.ForceSave = true;
                        config.Save(ConfigurationSaveMode.Full);
                    }
                }
                catch (ConfigurationErrorsException err)
                {
                    //manage exception - give feedback or whatever
                }

            }

Se creará la siguiente definición de CustomSection y la CustomSection real:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
  </configSections>
  <CustomSection LastName="TEST" FirstName="TEST" />
</configuration>

Ahora recupere las propiedades de su sección:

    CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
    string lastName = section.LastName;
    string firstName = section.FirstName;

Otros consejos

Si puedo salirme con la mía, simplemente usaré App.Config; sin embargo, si necesito algo más complejo, usaré secciones de configuración personalizadas.Sí, es complicado entenderlo al principio, pero en mi opinión, vale la pena invertir tiempo en una fuente de configuración unificada y una configuración familiar para todas las configuraciones.

Coloque su configuración en una base de datos.Si ejecuta su aplicación en más de una máquina (por ejemplo, una aplicación cliente-servidor), entonces todos los sistemas de configuración por máquina son un PITA.Un área de configuración única es la mejor manera de colocar su configuración.Escribe una interfaz gráfica de usuario para administrarlo y estarás muy feliz.

Implementación de archivos app.config en 200 cajas de clientes.No es divertido, especialmente cuando uno se pierde (y lo hacen, créanme).

En el pasado fui administrador de redes/sistemas y ahora desarrollo utilidades internas para aplicaciones de bases de datos.Lo que he encontrado es esto:

Los archivos de configuración simples no anidados son los mejores para aplicaciones que no cambiarán mucho el lugar donde acceden a sus recursos.

Cualquier cosa más compleja debe ingresar a una base de datos con una interfaz de usuario de administración.Esto sólo se aplica a los usuarios comerciales habituales.Si le preocupa que la base de datos se corrompa, utilice el enfoque del archivo de configuración complejo.Los archivos tienden a corromperse menos que las bases de datos.

Ahora, si sus usuarios son otros desarrolladores, tendrá mucha más flexibilidad sobre qué usar para almacenar sus configuraciones.

Encuentro NombreValorCollectionHandler el mejor y más fácil, y generalmente lo vincularía a un archivo de configuración externo a través del atributo configSource.

Intento poner la configuración MÍNIMA ABSOLUTA en archivos de configuración, y la mayor parte está configurada en código con una aplicación que es consciente de su entorno de implementación (como por nombre de máquina o dirección IP, si se conoce).Por supuesto, esto requirió mucha más planificación previa y conocimiento de sus entornos, pero muchos menos dolores de cabeza durante la implementación.

Utilizo un archivo de configuración xml personalizado, donde se usa un archivo de configuración diferente para cada entorno (dev/qa/prod).Los archivos de configuración son plantillas de las que se crean instancias dinámicas con elementos como configuraciones de host/puerto para servicios; esto hace que los entornos múltiples y la conmutación por error sean muy fáciles, ya que pueden manejarse mediante el código de creación de instancias de la plantilla.

Por supuesto, si tiene muy poca configuración y no le preocupan múltiples entornos, entonces app.config es más estándar y probablemente sea la mejor manera de hacerlo.

Creo que las configuraciones clave/valor funcionan bastante bien para archivos de configuración simples.Se convierte en un problema cuando el archivo comienza a crecer y es difícil de mantener.Comenzamos a dividir el archivo de configuración en configuraciones de aplicaciones "comunes" y "específicas".El acceso a los archivos es transparente para la aplicación, los valores "comunes" son los mismos en la mayoría de los casos, pero los "específicos" difieren para cada aplicación implementada.

Utilizo un archivo de configuración xml personalizado.Cada configuración tiene una clave, un valor y un tipo.

Tiene una sección principal que contiene todas las configuraciones y secciones adicionales que contienen anulaciones de configuraciones para entornos particulares (desarrollo, preparación, en vivo).No necesito reemplazar secciones del archivo al implementar.Tengo un pequeño contenedor al que puedes llamar para obtener una configuración particular o un diccionario que los contenga todos.

Recientemente creé un plantilla T4 eso leerá el archivo de configuración y creará una clase de configuración estática fuertemente tipada.Ha sido un gran ahorro de tiempo.

Mantengo la mayor parte de mi configuración en el contenedor IoC, p.Primavera.Net.

Si tiene .NET 3.0 disponible, XamlReader/XamlWriter me resulta muy útil para almacenar configuraciones.Pueden escribir/leer cualquier objeto .NET en XAML si:

  • El objeto tiene un constructor sin parámetros.
  • Las propiedades para leer/escribir tienen captadores y definidores públicos.

Es especialmente bueno que no tengas que decorar los objetos de configuración con ningún atributo.

dataset.WriteXML()/dataset.ReadXML() funciona bastante bien para mí cuando app.config ya no es suficiente.

Principalmente prefiero usar un archivo xml personalizado y un método de serialización Xml para leer y escribir estos archivos de configuración...No restringido a pares clave/valor y no complejo de implementar...

Tuve buena suerte al crear mi propia clase especial que devuelve datos de configuración de un archivo ".settings" asociado con el ensamblado que realiza la llamada.El archivo es XML y la clase de configuración lo expone públicamente como un XDocument.Además, el indexador de esta clase de configuración devuelve valores de elementos de los nodos /settings/setting.

Funciona muy bien para aplicaciones simples donde solo necesita un par clave/valor para acceder a la configuración, y funciona muy bien para configuraciones complicadas donde necesita definir su propia estructura y usar System.Xml.Linq para consultar el documento XML.

Otro beneficio de implementar el suyo propio es que puede usar FileSystemWatcher y el tipo de acción de devolución de llamada para activar automáticamente un método cuando el archivo cambia en tiempo de ejecución.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top