Хранение данных в файле web.config (пользовательский раздел / элемент appSettings) против хранения их в классе

Question

Почему лучше хранить данные внутри элемента appSettings (или внутри пользовательского раздела) файла web.config, чем хранить его в классе?

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

Спасибо

Answer 1

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

Жесткое программирование чего-либо настраиваемого является рецептом неудачи, и оно абсолютно вас укусит - это всего лишь опыт, если вы не верите этому, вам остается только подождать!

Answer 2

Размещение данных в файле web.config также позволяет запускать один и тот же код в разных средах с разными данными, зависящими от среды. Это может означать запуск одного и того же кода веб-сайта при подготовке со строкой соединения с тестовой базой данных и в производственной среде со строкой соединения с производственной базой данных. Или это может означать, что разработчики могут настраивать данные для своих собственных тестов без изменения какого-либо кода, как упоминалось в «annakata».

Answer 3

Дело не просто в перекомпиляции кода, а в повторном развертывании кода. Обычно вы не развертываете код на веб-сервере, вы просто развертываете двоичные файлы и файлы aspx / html. Если вы жестко закодировали свои данные конфигурации в коде, вам придется пересобрать и заново развернуть библиотеку или приложение, чтобы передать изменения на сервер, что гораздо сложнее, чем просто обновить web.config.

Answer 4

Поместив настройки в web.config, вы получите их все в централизованном месте.

Также при развертывании веб-сайта может потребоваться его предварительная компиляция один раз. Таким образом, вы не сможете впоследствии изменить источник (без повторной компиляции).

Answer 5

Просто намного проще управлять и обновлять настройки.

Если вы используете Notepad для разработки и выкладываете код на сервер, я согласен, что выгода от этого невелика, но если вы используете Visual Studio и build ваш сайт и публикуйте его, вы публикуете предварительно скомпилированные dll, а не просто обновляете текстовый исходный код (файлы .cs или .vb) на сервере. Поэтому, когда приходит время обновить настройку в этот момент, все в файле web.config можно обновить, просто изменив текстовый файл, при этом, как и в случае других изменений, вам придется перекомпилировать весь веб-сайт и опубликовать его.

И, исходя из опыта, это становится непросто, когда мы вступаем во владение другими разработчиками, которые не заботятся о том, чтобы все, что нужно для работы веб-сайта, находилось под контролем исходного кода. Теперь я застрял на веб-сайте, на котором мы не можем обновлять огромные куски из-за (любезно говоря) нестандартных практик в прошлом.

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

Будьте добры к нему или ей. Упростите внесение простых изменений.