Comprender las opciones de configuración de .Net

Question

Estoy realmente confundido por las diversas opciones de configuración para .Net de dll, sitios web ASP.net, etc. en .Net v2, especialmente cuando se considera el impacto de un archivo de configuración en el extremo de la cadena de la interfaz de usuario/usuario final.

Entonces, por ejemplo, algunas de las aplicaciones con las que trabajo usan configuraciones a las que accedemos con:

string blah = AppLib.Properties.Settings.Default.TemplatePath;

Ahora, esta opción parece interesante porque los miembros están fuertemente escritos y no podré escribir un nombre de propiedad que no exista en Visual Studio 2005 IDE.Terminamos con líneas como esta en App.Config de un proyecto ejecutable de línea de comandos:

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(Si no tenemos la segunda configuración, alguien que haya liberado un archivo dll de depuración en el Live Box podría haberlo compilado con la cadena de conexión de depuración incrustada en él - eek)

También tenemos configuraciones a las que se accede de esta manera:

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

Ahora, esto parece interesante porque podemos acceder a la configuración desde el código dll o el código exe/aspx, y todo lo que necesitamos en la Web o App.config es:

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

Sin embargo, es posible que el valor, por supuesto, no esté establecido en los archivos de configuración, o que el nombre de la cadena esté mal escrito, por lo que tenemos un conjunto diferente de problemas.

Entonces...Si tengo entendido que es correcto, los métodos anteriores dan una escritura fuerte pero no comparten valores entre el dll y otros proyectos.Este último proporciona un mejor intercambio, pero una escritura más débil.

Siento que me debe faltar algo.Por el momento, ni siquiera me preocupa que la aplicación pueda reescribir valores en los archivos de configuración, encriptar ni nada por el estilo.Además, había decidido que la mejor manera de almacenar cualquier cadena que no fuera de conexión era en la base de datos...y luego lo siguiente que tengo que hacer es almacenar números de teléfono para enviar mensajes de texto a las personas en caso de problemas de conexión a la base de datos, por lo que deben almacenarse fuera de la base de datos.

Answer 1

Nij, nuestra diferencia de pensamiento proviene de nuestras diferentes perspectivas.Estoy pensando en desarrollar aplicaciones empresariales que utilicen predominantemente clientes WinForms.En este caso, la lógica empresarial está contenida en un servidor de aplicaciones.Cada cliente necesitaría saber el número de teléfono a marcar, pero colocarlo en el App.config de cada cliente plantea un problema si ese número de teléfono cambia.En ese caso, parece obvio almacenar la información de configuración de la aplicación (o la configuración de toda la aplicación) en una base de datos y hacer que cada cliente lea la configuración desde allí.

La otra forma, .NET (hago la distinción porque, en los días anteriores a .NET, almacenamos la configuración de la aplicación en tablas de base de datos) es almacenar la configuración de la aplicación en el archivo app.config y acceder a través de la clase de configuración generada. .

Estoy divagando.Tu situación suena diferente.Si todas las aplicaciones diferentes están en el mismo servidor, puede colocar la configuración en un web.config en un nivel superior.Sin embargo, si no es así, también podría tener un "servicio de configuración" separado con el que las tres aplicaciones hablan para obtener sus configuraciones compartidas.Al menos en esta solución no se replica el código en tres lugares, lo que aumenta la posibilidad de problemas de mantenimiento al agregar configuraciones.Aunque suena un poco exagerado.

Mi preferencia personal es utilizar configuraciones de tipo fuerte.De hecho, genero mi propia clase de configuración fuertemente tipada en función de cuál es mi tabla de configuración en la base de datos.De esa manera puedo tener lo mejor de ambos mundos.Intellisense a mi configuración y configuración almacenada en la base de datos (nota:eso es en el caso en el que no hay un servidor de aplicaciones).

También estoy interesado en aprender las estrategias de otras personas para esto :)

Answer 2

Si usa la pestaña de configuración en VS 2005+, puede agregar configuraciones fuertemente tipadas y obtener intellisense, como en el primer ejemplo.

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

Esto se almacena físicamente en App.Config.

Aún puede usar el elemento appSettings del archivo de configuración, o incluso crear sus propias subclases ConfigurationElementCollection, ConfigurationElement y ConfigurationSection.

En cuanto a dónde almacenar su configuración, base de datos o archivo de configuración, en el caso de cadenas sin conexión:Depende de la arquitectura de su aplicación.Si tiene un servidor de aplicaciones compartido por todos los clientes, utilice el método mencionado anteriormente en App.Config en el servidor de aplicaciones.De lo contrario, es posible que tengas que utilizar una base de datos.Colocarlo en App.Config en cada cliente causará dolores de cabeza con el control de versiones/implementación.

Answer 3

Creo que su confusión proviene del hecho de que parece que su primer ejemplo es una biblioteca casera, que no forma parte de .NET.El ejemplo del administrador de configuración es un ejemplo de funcionalidad integrada.

Answer 4

Apoyo la respuesta de Rob Gray, pero quería agregarle un poco.Esto puede ser demasiado obvio, pero si está utilizando varios clientes, app.config debería almacenar todas las configuraciones específicas de la instalación y la base de datos debería almacenar prácticamente todo lo demás.

Las aplicaciones de cliente único (o servidor) son algo diferentes.Aquí realmente se trata de una elección más personal.Una excepción notable sería si la configuración es el ID de un registro en la base de datos, en cuyo caso siempre almacenaría la configuración. en la base de datos con una clave externa para garantizar que la referencia no se elimine.

Answer 5

Sí, creo que estamos en la situación de dolor de cabeza que describe Rob: tenemos algo así como 5 o 6 sitios web y aplicaciones diferentes en tres servidores independientes que necesitan acceder a la misma base de datos.Tal como están las cosas, cada uno tiene su propio Web o App.config con la configuración descrita y/o anulando la configuración en nuestra biblioteca dll principal de DB-access.

Rob: cuando dices servidor de aplicaciones, no estoy seguro de a qué te refieres.Lo más parecido que se me ocurre es que al menos podríamos compartir algunas configuraciones entre sitios en la misma máquina colocándolas en un web.config superior en la jerarquía de directorios...pero esto tampoco es algo que haya podido investigar...habiendo pensado que es más importante comprender cuál de las rutas de tipo fuerte o débil es "mejor".