it-roy-ru.com

Почему GetEnvironmentVariable рекомендуется использовать поверх AppSettings при чтении переменных среды в функциях Azure

В документации Microsoft говорится, что

Параметры приложения можно прочитать из переменных среды как при локальной разработке, так и при работе в Azure. При локальной разработке параметры приложения берутся из коллекции значений в файле local.settings.json. В обеих средах, локальной и Azure, GetEnvironmentVariable ("") извлекает значение параметра именованного приложения. Например, когда вы работаете локально, «Имя моего сайта» будет возвращено, если ваш файл local.settings.json содержит {«Значения»: {«WEBSITE_SITE_NAME»: «Имя моего сайта»}}.

Свойство System.Configuration.ConfigurationManager.AppSettings имеет значение альтернативный API для получения значений параметров приложения, но мы рекомендуем что вы используете GetEnvironmentVariable, как показано здесь.

Не указано, почему это рекомендуемый способ.

  • Есть ли у нее преимущества в производительности?
  • Есть ли случай, когда чтение из AppSettings приведет к пустому значению?
  • Это просто для совместимости с различными форматами конфигурации (например, json, xml и т.д.)?

Или я просто принимаю это как факт жизни, не зная, почему?

6
Tarek

Есть ли у нее преимущества в производительности?

Я скажу, как правило, это делает на основе моего теста. GetEnvironmentVariable немного быстрее, чем ConfigurationManager, на моем компьютере (в 100 раз) его среднее время выполнения примерно на 20 мкс короче, а в Azure (план обслуживания приложения B1, в 10 раз) короче на 12 мкс. Это статистический вывод, так как ConfigurationManager иногда может быть быстрее.

Есть ли случай, когда чтение из AppSettings приведет к пустому значению?

Если значения, которые должны быть прочитаны, установлены так, как ожидалось, может быть только один сценарий, который мы получим нулевым, используя ConfigurationManager-- в функции v2, где это больше не полезно.

Это просто для совместимости с различными форматами конфигурации (например, json, xml и т.д.)?

У GetEnvironmentVariable такой возможности нет, и нет необходимости в совместимости форматов. По своему замыслу функции Azure получают конфигурацию из local.settings.json при локальной разработке, когда при запуске функции Host параметры приложения в Values импортируются в переменные среды текущего процесса. Так что нет формата рассмотрения.

В заключение, GetEnvironmentVariable

  • кратко - нет необходимости импортировать сборку System.Configuration для использования ConfigurationManager.
  • универсальный - как для v1, так и для v2, локальной среды и среды Azure (не включает ConnectionStrings в local.settings.json).
  • быстрее - вероятно, не так надежно, я использую простые циклы, чтобы повторить триггер с секундомером для измерения (все журналы отключены).

Конечно, мы все еще можем использовать ConfigurationManager в функциях v1, и мы должны использовать его, если хотим получить ConnectionStrings локально.

4
Jerry Liu

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

0
joey