.net - manager - ¿Por qué la gente recomienda constantemente usar appConfig en lugar de usar los archivos de configuración?(.RED)

leer appsettings vb net

Question

Muy a menudo veo la respuesta a la pregunta como: "¿Cómo debo almacenar la configuración en mi aplicación .NET?" es editar el archivo app.config agregando entradas manualmente a app.config (o web.config) de esta manera:

<configuration>
<appSettings>
**<add key="ConfigValueName" value="ABC"/>**
</appSettings>
</configuration>

Luego, accediendo a ellos como:

string configValue = Configuration.AppSettings["ConfigValueName"];

Me referiré al enfoque descrito anteriormente como el enfoque "app.config". Muy rara vez veo personas que recomiendan agregar un archivo de "Configuración" al proyecto. He visto esto tantas veces en la web y en stackoverflow ... Estoy empezando a preguntarme si me estoy perdiendo algo ... porque no estoy seguro de por qué usarías este método en lugar de usar una "Configuración " archivo. No entré en .NET hasta el VS2005, por lo que una teoría que tengo es cómo se hicieron las cosas en el VS2003 y ¿la gente nunca cambió?

Ejemplos de personas que recomiendan el enfoque app.config:

• La forma más sencilla de tener un archivo de configuración en una aplicación C # de Windows Forms
• Prácticas recomendadas: ¿cómo debo almacenar la configuración en C # (Formato / Tipo)?

Desde mi punto de vista, existen las siguientes ventajas del enfoque "Archivo de configuración":

1. Se puede usar tanto para la Configuración de la aplicación (que son comunes para todos los usuarios) como para la Configuración del usuario desde la misma interfaz.
2. Posibilidad de utilizar el soporte de diseñador de configuración en Visual Studio. Menos propenso a errores y luego editar un archivo XML directamente IMHO.
3. Refactorización: puede cambiar el nombre de una configuración particular y actualizará automáticamente las referencias en su código.
4. Compilación de verificación de tipo.
5. Soporte de autocompletado.
6. Capacidades de propiedad de la red. Descubrí que el control PropertyGrid es una forma muy fácil de hacer un formulario de opciones rápidas. Simplemente haces propertyGrid1.SelectedObject = Settings1.Default; y tu estas listo.

En caso de que no esté seguro de lo que quiero decir con el enfoque del archivo de "Configuración", consulte esta publicación, que es uno de los pocos ejemplos en los que alguien recomienda usar los archivos de Configuración en lugar de app.confg.

EDITAR: Entienda: la intención de este tema es averiguar por qué las personas utilizarían el enfoque de aplicación.configuración descrito anteriormente sobre el enfoque del archivo de configuración. Me he encontrado con las limitaciones del enfoque del archivo de configuración y me he visto obligado a lanzar mi propia solución personalizada a veces. Esa es una discusión completamente diferente .

Answer 1

Creo que la mayor diferencia entre los dos es que la aplicación no puede cambiar los valores en app.config . Esos valores se leen en tiempo de ejecución y no hay soporte incorporado para escribir nuevos valores en el archivo de configuración.

Los archivos de configuración se pueden cambiar usando el comando Save() .

Un problema importante con la compatibilidad integrada con los archivos de configuración es dónde se almacena el archivo de configuración. Si observa su carpeta APPDATA, verá que hay una carpeta con el nombre de la empresa, luego una subcarpeta con el nombre del producto, luego una subcarpeta con un nombre semi-aleatorio e información de la versión .

Cada vez que lance una nueva versión, no ubicará el archivo de configuración de la versión anterior debido a la ubicación donde está almacenado el archivo de configuración. Tampoco hay forma de cambiar el lugar donde se almacena el archivo de configuración.

Lo utilicé en un proyecto y lo encontré mucho más útil para crear mi propia clase AppSettings que usa un archivo XML para la configuración. Tengo control sobre el formato y la ubicación del archivo.

Answer 2

Debido a que la infraestructura de archivos de configuración es (1) más compleja y (2) insuficientemente documentada dada su complejidad.

La forma en que funcionan los archivos de configuración de forma predeterminada son útiles para aplicaciones pequeñas. Para los más grandes, a menudo es necesario cambiar este valor predeterminado. La infraestructura del archivo de configuración podría aprovecharse según sus necesidades, pero existe una curva de aprendizaje empinada, incluso con buena documentación. Sin documentación, es casi inútil.

Solo remito a this artículo para concluir. Siéntase libre de pegar algunos enlaces útiles a la documentación conceptual de MSDN para contradecir mi argumento.

Actualizar:

Necesito ser justo y proporcionar un caso de uso específico que no encontré documentado:

Me gusta el diseñador de configuración de la aplicación. También me gusta el formato XML de la configuración almacenada. Quería conservar estas funciones, pero usar otras ubicaciones donde almacenar las configuraciones. No encontré ningún indicio de si este caso de uso era compatible y, en caso afirmativo, cómo realizar la tarea.

Answer 3

Dos escenarios:

• Una aplicación cliente que se envía con los ajustes de configuración establecidos en valores predeterminados. La aplicación proporciona una interfaz de usuario para modificar la configuración de un solo usuario o de todos los usuarios.

Aquí el enfoque de "configuración" gana sin lugar a dudas.

• Una aplicación que consta de varios ensamblajes relativamente independientes, cada uno de los cuales requiere unos pocos ajustes de configuración simples. Las configuraciones normalmente las establece un administrador y no son modificadas por la aplicación una vez implementadas.

Aquí "appSettings" puede ser mucho más simple de administrar. Con el enfoque de "configuración", habrá una sección para cada ensamblaje configurable que se agregará al archivo de configuración principal de la aplicación.

Answer 4

Hay una tercera, y mucho, mucho mejor manera que AppSettings o Propiedades: secciones de configuración personalizada . Ventajas sobre AppSettings:

1) Acceso fuertemente tipado

2) Mecanismos de validación incorporados tanto para el esquema como para el formulario.

3) Basado en POCO, lo que lo hace altamente comprobable: solo tiene que crear su propia configuración de prueba.

4) No hay confianza en las cuerdas mágicas. No es que no pueda ajustar fácilmente los Ajustes de Aplicación en una clase y acceder a ellos de esa manera, pero el 95% de los desarrolladores no lo hacen.

5) XML en la configuración se vuelve mucho más inteligible una vez que llegue a una docena de ajustes. También mucho más inteligible que los bits Propterties IMHO.

6) No confíes en Visual Studio para que funcione bien.

Por supuesto, nunca utilicé las propiedades porque primero tuve en cuenta las secciones de configuración personalizadas.

Por cierto, si no ha oído hablar de ellos, todavía los está usando todos los días. ¿Cuáles cree que son las secciones de configuración estándar en los archivos de configuración de .NET?

_____ SECCION DE CLAUSULACION

Primero, la mayor parte de esto estaba orientado hacia el enfoque de AppConfig, y al volver a leer no estaba claro. En general, creo que estamos en el mismo lado: evite la bolsa de nombre-valor para la configuración porque se rompe con demasiada facilidad. También debo agregar que soy un tipo web, por lo que las configuraciones de usuario son algo que vive en la capa de aplicación, no en la configuración, para mí.

1) Es cierto que tanto las Propiedades como las secciones de configuración personalizadas tienen un acceso fuertemente tipado. AppSettings no lo hacen. AppSettings mal, apoyos / CC bueno.

2) Cuando carga una sección de configuración, la aplicación lanzará una excepción de configuración si no expone la información necesaria o la información incorrecta. Igual que cuando eliminas un app.config o web.config. Hay un poco más de infraestructura de validación que no he usado porque me gusta fallar demasiado pronto o nada.

3) POCO es un antiguo objeto C # en caso de que alguien se haya perdido los últimos años. De todos modos, debido a que las configuraciones de configuración son decorativas y se declaran a través de atributos, sus configuraciones de configuración pueden probarse fácilmente porque solo necesita delcitar una nueva MyConfigSection () y establecer propiedades, etc., según corresponda. Según entiendo las propiedades, debe tener el archivo de configuración allí con el xml correcto o usted es sol. Otra ventaja es que las secciones de configuración personalizadas funcionan con todas las demás cosas interesantes que puede hacer con POCO, como las interfaces y la inyección de dependencias.

4) Es cierto que tanto las Propiedades como las secciones de configuración personalizadas están fuertemente escritas, AppSettings no. AppSettings mal, apoyos / CC bueno.

5) Realmente orientado a la AppSettings. He heredado algunas aplicaciones con literalmente 2 páginas de <add name="foo" value="bar" /> en la configuración. Eso es fácil en comparación con el jibberish xml que las propiedades escupen. Por otro lado, su sección de configuración personalizada puede ser más bien semántica y autoexplicativa porque está declarando los nombres y atributos de la sección. Puedo editarlo fácilmente en el bloc de notas en el servidor de producción y no estar demasiado nervioso por dispararme en el pie en caso de apuro.

Por lo tanto, aparte de no tener una cuadrícula de propiedades basada en VS (que yo diría que es algo malo, ¿por qué necesita una cuadrícula para editar la configuración?), Las secciones de configuración personalizada tienen muchas ventajas y no tienen desventajas reales en comparación con las Propiedades. Tanto las secciones de configuración personalizadas como las propiedades tienen enormes ventajas sobre los ajustes de aplicaciones.

Answer 5

Incorrecto: parte del problema con el enfoque del archivo de configuración es que requiere que la aplicación esté en un lugar específico y que el archivo de configuración esté en el lugar correcto. Si uno de estos se mueve accidentalmente, entonces la configuración se puede perder para siempre, igual que si se eliminara. También puede haber el problema de varios archivos de configuración con el mismo nombre en la carpeta, lo que hace que se sobrescriba uno. Esto es particularmente malo si el software depende del archivo de configuración. Estos problemas no son tan pronunciados con el software instalado, pero en el software que no está instalado, simplemente descargarlo y ejecutarlo puede ser un problema importante. Imagine que alguien haya descargado varios de estos programas en el mismo directorio y todos hayan usado el mismo nombre de archivo de configuración.

EDITAR: Como se discutió con la persona que hizo la pregunta, esta respuesta es incorrecta porque la pregunta se refiere a dos formas diferentes de guardar en un archivo de configuración. Cuando di mi respuesta, pensé que se refería a dos archivos diferentes. La única otra respuesta que puedo dar es que es una cuestión de preferencia personal.

Answer 6

Sin la discusión, entonces la respuesta es:

"Porque es más fácil".

Answer 7

También me gustaría señalar una diferencia entre la aplicación. Configuración y la ventana Configuración. Si guarda algo en Configuración, la configuración se guardará en las siguientes ubicaciones.

Win XP: c: / Documents and Settings /% Username% / Local Settings / Application Data {Nombre del editor} /

Win 7: C: / Users /% Username% / AppData / Local {Nombre del editor} /

Mientras que la configuración de app.config se guarda solo en el archivo de configuración.