Хранение строк подключения в machine.config по сравнению с хранением их в web.config
Функциональная поддержка.
Генераторы и выражения генератора, конкретно.
Ruby сделал эту господствующую тенденцию снова, но Python может сделать это точно также. Не столь повсеместный в библиотеках как в Ruby, который слишком плох, но мне нравится синтаксис лучше, это более просто.
, поскольку они не так повсеместны, я не вижу как много примеров там на том, почему они полезны, но они позволили мне писать инструменту для очистки, более эффективному коду.
4 ответа
Лично я никогда не сохраню свои строки подключения в моем файле machine.config, только в web.config.
Вы говорите, что это выделенный сервер, но выделен ли этот сервер для одного веб-приложения?
Если нет, то теперь у вас есть один файл (machine.config), который эффективно обменивается данными конфигурации для нескольких (возможно, не связанных) веб-приложений. В зависимости от количества этих приложений, и если вам когда-либо понадобится переместить их на другой сервер, использование machine.config может стать очень запутанным.
Даже если сервер выделен для одного веб-приложения , вы, вероятно, будете выполнять разработку и тестирование на других машинах. Поскольку machine.config обычно не является файлом, включенным в набор файлов проекта веб-приложения ASP.NET, вам, вероятно, придется изо всех сил развертывать machine.config для каждого из различных dev / test / production, и убедитесь, что другая конфигурация (не связанная со строкой подключения) в них верна для этого компьютера.
Использование Интернета. config для хранения строк подключения к базе данных имеет вполне логичный смысл и полностью ожидается почти всеми разработчиками ASP.NET, даже если у вас есть несколько приложений, которые будут использовать одну и ту же базу данных на одном и том же сервере базы данных. Сохранение этой конфигурации в web.config каждого приложения позволяет каждому из этих приложений быть более самодостаточным и не зависеть от какого-либо другого «внешнего» файла.
Обычно я просматриваю файл machine.config и то, что использует сама структура. , и он принадлежит машине и специфичен для этой машины. Я очень редко захожу и сам прикасаюсь к нему. Я рассматриваю web.config как файл, который является неотъемлемой частью вашего проекта веб-приложения и "перемещается" вместе с этим проектом по мере его перемещения и развертывания на разных машинах.
Кроме того, не забывайте, что многое из того, что '
Я всегда буду использовать web.config на том основании, что это именно то место, где все ожидают. Нет смысла доставлять человеку, который должен поддерживать веб-сайт, больше трудностей, храня строки подключения в необычном месте.
ДОПОЛНИТЕЛЬНО
На основании дополнительной информации, что OP заинтересован в аспекте безопасности, скорее чем и общая причина, по которой я добавил следующее.
Я все равно не буду хранить строки подключения в machine.config. Если вы это сделаете, любое приложение .NET, работающее на машине, получит доступ к вашим строкам подключения.
web.config - это защищенный файл. IIS не будет обслуживать его по умолчанию, если вы не сделаете что-нибудь для его неправильной настройки.
Если безопасность является вашей основной заботой, сконцентрируйтесь на блокировании базы данных и разрешений пользователей. Разница в безопасности между файлом .config web / machine минимальна. Ответ Колина правильный. Я бы проголосовал или прокомментировал там, но у меня еще нет куража!
security wise you could look into storing your connection strings in there own encrypted .config file that your web.config file would have a reference to.