Проблемы с производительностью при повторных вызовах ConfigurationManager.AppSettings для получения значений параметров приложения? - PullRequest
Новая
       6

Проблемы с производительностью при повторных вызовах ConfigurationManager.AppSettings для получения значений параметров приложения?

9 голосов
/ 22 июля 2011

Я работаю над базой кода, в которой много идентичных вызовов ConfigurationManager.AppSetting, разбросанных по всему.

Похоже ли это на возможную проблему производительности?

Или потому, что данные очень малы, тривиальны и не «дороги»?Постоянно возвращаясь к файлу для получения данных, или среда выполнения .NET кэширует файл / значения / вызовы?

Если это не проблема производительности, это просто неорганизованный подход к доступу к конфигурации приложениязначений, и нужно ли просто пересматривать, чтобы обеспечить более чистую и последовательную реализацию доступа к настройкам?

Ответы [ 2 ]

14 голосов
/ 23 июля 2011

Я бы сказал, что это скорее проблема сопровождения кода, чем проблема производительности. Простой поиск по словарю AppSettings не будет проблемой, если у вас нет кода, который пытается выполнить поиск по AppSettings в цикле, который выполняется, скажем, сто раз. Конечно, такой код вызовет проблемы с производительностью. Но еще важнее то, что у вас будет ConfigurationManager.AppSettings["MyKey"] по всей базе кода. Вы вводите волшебную строку. Если вам нужно изменить ключ в файле конфигурации, вам придется выполнить тщательный поиск и замену во всех ваших проектах. Более того, мы обычно принимаем некоторые решения, основываясь на значении, хранимом в appSettings. Это не всегда просто читать и использовать значение как есть. Иногда вы принимаете решение на основе стоимости. Например, 

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

Возможно, вы повторяете эту логику в сотнях мест. Допустим, вам нужно добавить еще одно условие: 

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

Это становится грязным. Ваш код начинает вонять.

Итак, я всегда рекомендую моей команде разработчиков никогда не использовать ConfigurationManager.AppSettings где-либо в коде. Используйте некоторый статический класс, где вы читаете значения конфигурации, и все такие решения передаются в одну переменную. Например, 

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

}

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

Это не только лучший по производительности, но и легко поддерживаемый и расширяемый код.

3 голосов
/ 22 июля 2011

Несколько вещей здесь.

  1. Вы можете проверить, если это проблема с производительностью, используя что-то вроде ANTS Profiler или DotTrace, которая позволяет вам проверять производительность приложения
  2. Я бы сказал, что вы МОЖЕТЕ быть открытыми для некоторых проблем в будущем, если вы будете разбрасывать вызовы повсюду, подумайте, например, если вы решите изменить имя одного из параметров приложения, это может привести к катастрофическим последствиям. Я лично рекомендую централизовать этот тип вещей, если по какой-либо причине учтены будущие изменения.
  3. С точки зрения производительности, будьте осторожны, чтобы не «предварительно оптимизировать» то, что просто не нужно, в конечном итоге вы можете добавить больше сложности, когда это просто не нужно.
...