2011-07-22 20 views
8

Estoy trabajando en una base de código que tiene muchas llamadas idénticas de ConfigurationManager.AppSetting repartidas por todas partes.¿Problemas de rendimiento con llamadas repetidas a ConfigurationManager.AppSettings para obtener valores de aplicación?

¿Esto suena como un posible problema de rendimiento?

¿O porque la información es muy pequeña es trivial y no 'costosa'? Volviendo constantemente al archivo para obtener los datos, ¿el caché de tiempo de ejecución de .NET guarda el archivo/valores/llamadas?

Si esto no es un problema de rendimiento, ¿es solo un enfoque desorganizado para acceder a los valores de configuración de la aplicación, y debería volver a factorizarse para una implementación más limpia y consistente de acceder a la configuración?

+1

Personalmente utilizo ConfigurationManager y no tengo problemas con él y me resulta muy sencillo cambiar la configuración sin tener que volver a compilar el problema. A menos que pueda obtener otra forma de memoria persistente para guardar su configuración, entonces el acceso a archivos a través del ConfigurationManager me parece lo mejor. –

Respuesta

11

Yo diría que es más un problema de mantenimiento del código que un problema de rendimiento. Una simple búsqueda de diccionario en AppSettings no va a ser un problema a menos que tenga un código que intente realizar la búsqueda en AppSettings en un bucle que se ejecute, por ejemplo, cien veces. Seguramente tal código causará un problema de rendimiento. Pero aún más importante es que tendrá ConfigurationManager.AppSettings["MyKey"] en toda la base de código. Estás presentando una cadena mágica. Si tiene que cambiar la clave en su archivo de configuración, tendrá que hacer una búsqueda exhaustiva y reemplazarla en todos sus proyectos. Además, generalmente tomamos una decisión basada en el valor almacenado en appSettings. No siempre se lee de forma clara y se usa el valor tal como está. A veces tomas decisiones basadas en el valor. Por ejemplo,

if (ConfigurationManager.AppSettings["DebugMode"] == "yes") 
    do this 
else 
    do that 

Puede estar repitiendo esta lógica en cientos de lugares. Ahora supongamos que necesita agregar otra condición allí:

if (ConfigurationManager.AppSettings["DebugMode"] == "yes" || ConfigurationManager.AppSettings["InternetNotAvailable"] == "yes") 
    do this 
else 
    do that 

Esto se complica. Tu código comienza a apestar.

Por lo tanto, siempre recomiendo a mi equipo de desarrollo que nunca use ConfigurationManager.AppSettings en ningún lugar del código. Use alguna clase estática donde lea los valores de configuración y todas esas decisiones se guardarán en una sola variable. Por ejemplo,

static class ConfigHelper 
{ 
    private readonly static bool ExternalWebserviceCallAllowed = ConfiguationManager.AppSettings["DevMode"] == "false" && ConfigurationManager.AppSettings["InternetAvailable"] == "true"; 

} 

. 
. 
if (ConfigHelper.ExternalWebserviceCallAllowed) 
    do this 
else 
    do that 

Esto no solo mejora el rendimiento, sino que también ofrece un código altamente mantenible y extensible.

+0

Gracias, también estoy viendo este tipo de patrón en otras bases de código. –

3

Algunas cosas aquí.

  1. puede validar si se trata de un problema de rendimiento mediante el uso de algo como hormigas Profiler o dotTrace que le permite inspeccionar el rendimiento de la aplicación
  2. diría que podría estar abierto para algunas cuestiones en el futuro Si distribuye llamadas por todos lados, piense por ejemplo si decide cambiar el nombre de una de las configuraciones de la aplicación, podría ser desastroso. Yo personalmente recomiendo centralizar este tipo de cosas si por alguna razón para permitir futuros cambios.
  3. Desde una perspectiva de rendimiento, tenga cuidado de no "preoptimizar" algo que simplemente no es necesario, puede terminar agregando más complejidad cuando simplemente no es necesario.
+0

Grandes puntos, en particular acerca de la pre-optimización :) –

Cuestiones relacionadas