2009-04-11 12 views
13

El sistema de configuración .NET 2.0 y superior es bastante potente y extensible, siempre que no desee cambiar el hecho de que todo proviene de archivos XML en el sistema de archivos.Lea la configuración de .NET desde la base de datos

En mi requerimiento, no puedo cambiar archivos ya que mi aplicación se ejecuta en un entorno administrado fuera de mi alcance, pero podría cambiar la base de datos de SQL Server.

Así que estoy buscando almacenar archivos de configuración o secciones en una tabla SQL, pero ¿cómo puedo vincular el sistema de configuración .NET 2.0 a esto?

¿Hay alguna manera de escribir un "proveedor de configuración personalizada" que lea sus secciones de configuración no desde un archivo * .config en el sistema de archivos, sino desde una tabla en la base de datos SQL?

He estado buscando crear mi propia ConfigurationSection o ConfigurationElement personalizada, o incluso una configuración personalizada per se, pero parece que siempre termino en el punto en que puedo extender el sistema de configuración en el sistema de archivos tanto como me gusta, pero no puedo hacerlo leer mis fragmentos XML de una tabla de base de datos .....

¿Qué me estoy perdiendo? ¿Alguien ha hecho esto y se preocupa por explicar/compartir?

Gracias! Marc

PD: También intenté simplemente leer el archivo XML de configuración en una cadena, y luego deserializarlo en el campo apropiado, p. ServiceModelConfigSection: eso no funciona, desafortunadamente, porque la clase base ConfigSection de alguna manera no implementa un método que se requiere para ser XML serializable ........ (YIKES !!!)

+0

¿Pero no tendría usted el problema del paradero para establecer la información de configuración para su conexión SQL? Una vez que tenga una conexión con la base de datos, puede cargar cualquier configuración que necesite. App.Config no es mucho más que una tabla de búsqueda. – sipwiz

+0

Sí, lo que intento lograr es configurar los servicios de WCF desde una base de datos. Esos archivos de configuración WCF son MUY GRANDES Y COMPLEJOS, y realmente no quiero descomponer todo eso en asignaciones atómicas. Me gustaría leer el XML de configuración de la base de datos y aplicarlo. –

+0

Ah, vale, eso tiene más sentido, puedo ver por qué las configuraciones de WCF desde una base de datos serían útiles. Sospecho que tiene usted razón y debe haber alguna forma de que App.Config lea como una secuencia o bloque de XML en lugar de un archivo. – sipwiz

Respuesta

5

Hay aquí un artículo que habla de hacer lo que estamos hablando:

http://www.wrox.com/WileyCDA/Section/Redirecting-Configuration-with-a-Custom-Provider.id-291932.html

En resumen lo que hacen es crear una versión derivada de ProtectedConfigurationProvider, que normalmente se utiliza para cifrar archivos .config. En el método Decrypt, en lugar de descifrar la información de configuración, se recupera de una base de datos.

+0

+1 - gracias, muy interesante! Todavía no puedo entender el "ProtectedConfigurationProvider" como una clase base ... ¡pero lo intentaré! –

+2

Hola Keltex - funciona - principalmente - pero es un HACK bastante horrible en mi opinión ... Lástima que no hay una forma "adecuada", agradable y oficial de conectar directamente los proveedores de configuración en el sistema de configuración .NET ... .. –

+0

@marc_s Estoy de acuerdo. Pero es una solución temporal. – Keltex

1

Usted puede probar Cinchoo framework para sus necesidades.

Es compatible con las entradas de lectura y escritura de configuración de archivos, registro, INI, base de datos, etc.

Aquí es la forma más sencilla de definir y utilizar el objeto de configuración utilizando el framework Cinchoo

namespace HelloWorld 
{ 
    #region NameSpaces 

    using System; 
    using Cinchoo.Core.Configuration; 

    #endregion NameSpaces 

    [ChoConfigurationSection("sample")] 
    public class SampleConfigSection : ChoConfigurableObject 
    { 
     [ChoPropertyInfo("name", DefaultValue="Mark")] 
     public string Name; 

     [ChoPropertyInfo("message", DefaultValue="Hello World!")] 
     public string Message; 
    } 

    static void Main(string[] args) 
    { 
     SampleConfigSection sampleConfigSection = new SampleConfigSection(); 
     Console.WriteLine(sampleConfigSection.ToString()); 
    } 

} 

primera vez , cuando ejecuta la aplicación, Cinchoo framework genera automáticamente la sección de configuración de la siguiente manera. Luego, puede controlarlos a través de la fuente de configuración o por código.

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <configSections> 
    <section name="sample" type="Cinchoo.Core.Configuration.ChoNameValueSectionHandler, Cinchoo.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b7dacd80ff3e33de" /> 
    </configSections> 
    <sample> 
    <add key="name" value="Mark" /> 
    <add key="message" value="Hello World!" /> 
    </sample> 
</configuration> 

¡Pruébelo!

3

Puede usar el mismo xml para el análisis de .NET cuando lee las secciones web.config y configuración con cierta reflexión.

Aquí está el sample code para hacerlo.

Aquí hay una clase que desea que se represente en xml.

public class TestConfiguration : ConfigurationSection 
{ 
    [ConfigurationProperty("optionalProperty", DefaultValue = "defaultValue")] 
    public string OptionalProperty 
    { 
     get { return (string)base["optionalProperty"]; } 
     set { base["optionalProperty"] = value; } 
    } 

    [ConfigurationProperty("requiredProperty", IsRequired = true)] 
    public string RequiredProperty 
    { 
     get { return (string)base["requiredProperty"]; } 
     set { base["requiredProperty"] = value; } 
    } 
} 

Así es como crea una instancia de ConfigurationSection usando XML de una cadena (o una base de datos). Esto fue tomado de las pruebas en GitHub que se vinculó en la entrada del blog anterior.

[TestMethod] 
public void Can_build_configuration_with_default_value_set() 
{ 
    var result = _configurationSectionBuilder 
     .BuildSection<TestConfiguration>("<config requiredProperty=\"required\" optionalProperty=\"setValue\"></config>"); 

    Assert.AreEqual("setValue", result.OptionalProperty); 
} 

Obtiene todos los .NET lift con este enfoque utilizando el espacio de nombres System.Configuration.

+1

¡Agradable! Esto funciono muy bien para mi. El único problema fue la necesidad de garantizar que mi XML no tuviera ningún CRLF/espacio en blanco líder. Aunque algunas personas dicen que confiar en métodos CLR privados como este es peligroso, es mucho menos esquemático para mí que el código que estoy tratando de refactorizar. Esto constituye un gran andamio para apuntalar algunas de estas cosas mientras ataco el problema principal. ¡Gracias de nuevo! – killthrush

Cuestiones relacionadas