Недавно я был вовлечен в исправление проекта веб-приложения и заметил предыдущую таблицу используемой базы данных разработчиков для параметров конфигурации вместо web.config (app.settings).Настройки настройки веб-приложения - рекомендации по использованию
Что следует использовать? web.config или таблицу базы данных? Что лучше?
Вещи должны идти в web.config в следующих ситуациях:
Они вещи, которые должны быть доступны, чтобы сделать базу данных доступной
Они»(строка подключения к БД!) re, которые, если они должны измениться, вы хотите, чтобы пул приложений обновился, или которые, судя по всему, вряд ли изменится.
Они вещи, которые должны быть доступны, если база данных недоступны для какой-либо причины (например, список адресов электронной почты и SMTP-сервер для отправки сообщений об ошибках, или местах, где файлы журналов принадлежат)
Вещи должны идти в базу данных в следующих ситуациях:
и ваша БД и ваш веб-слой использовать эту конфигурацию.
Вам необходимо изменить конфигурацию «на лету», не заставляя обновлять пул приложений.
Это говорит - если вы собираетесь поставить свой конфиг в базе данных вы, вероятно, хотите кэшировать его каким-то образом в веб-слой, так что вы не ударять дб без необходимости. Для этого я предлагаю класс Cache.
В дополнение ко всему вышесказанному вам также необходимо будет рассмотреть политику вашей компании для работы с вашими серверами. Если вам очень и очень сложно работать с db, может возникнуть смысл вкладывать вещи в web.config и наоборот.
Что вы имели в виду под этим? * И ваша БД, и ваш веб-слой используют эту конфигурацию. * – Sam 2013-04-26 06:55:18
Это имеет смысл, почему пред. dev использовал DB для настройки, идите с ним. У вас должен быть web.config, я думаю, что ASP.NET не может работать без него. Настройка конфигурации проекта должна быть включена в web.config (декларации пользовательских элементов управления, дополнительных сборок и т. Д.), Но пользовательские настройки или что-то конкретное в бизнес-логике может быть лучше в базе данных.
Нет. Я понимаю, что требуется web.config, но это раздел настроек приложения, о котором я не знал. В основном, я был под впечатлением от настроек приложения, - было легко и быстро вносить изменения там, где изменения конфигурации db немного беспорядочны. Вы правы в том, что не меняете предыдущую работу, если она не сломалась, не меняйте ее. – Rob 2010-12-07 17:03:38
Спорная проблема между разработчиками и администраторами баз данных в моей компании.
На мой взгляд, вы всегда должны использовать конфигурационные файлы для уровня приложения, только для чтения. Если настройки заданы пользователем или доступны для редактирования во время выполнения, вы можете или не захотите пересмотреть подход.
Я видел ситуации, когда настройки хранятся в базе данных, которые используются внутри хранимых процедур. Я вижу некоторые обоснования для этого, но это не критично, поскольку значение может быть передано процедурам через параметр.
Хорошая точка зрения хранит procs. Я думаю, что настройка в базе данных облегчает доступ к базе данных. Тем не менее, этот prev dev использовал все настройки для пользователя и приложения. – Rob 2010-12-07 17:10:26
Одним из соображений может быть то, что после развертывания веб-приложения разработчик больше не имел доступа к файлам web.config в производственной среде.
Если ему иногда нужно просматривать настройки, чтобы обеспечить любую форму поддержки, размещение настроек в базе данных, где он может получить доступ только для чтения к таблице конфигурации, может сделать тонны смысла.
Одним из преимуществ использования базы данных для настроек является то, что все может быть изменено «на лету», не нарушая создание веб-сайта.
Изменения в файле web.config приведут к перезагрузке рабочих процессов в IIS, и приложение будет перезапущено. Если вы используете сеансы InProcess, они будут потеряны. Это может привести к сбою ваших пользователей веб-сайта.
Мы используем комбинацию настроек web.config и настроек уровня базы данных.
Для каждой настройки мы задаем следующий вопрос: «Является ли этот параметр конкретным для аппарата, в котором работает приложение?» Если это так, то это идет в web.config. Если нет, то мы задаем дополнительный вопрос: «Если этот параметр изменен, должно ли приложение быть перезагружено?» Если да, web.config. Чаще всего перезагрузка не приемлема для наших соглашений об уровне обслуживания.
Большинство наших приложений являются многопользовательскими и/или запущены в веб-ферме. Простые вещи, такие как локальный путь файловой системы, уровень ведения журнала или строки подключения к базе данных, находятся в файле web.config. Причина в том, что они имеют дело с ресурсами, специфичными для этой машины.
Практически все остальное повлияет на выполнение программы и должно быть доступно как для приложений, так и для слоев данных. Кроме того, они, как правило, необходимы другим приложениям (при условии, что несколько приложений попадают в одну и ту же базу данных).
Один из вариантов использования для базы данных - это приложения с балансировкой нагрузки, такие как веб-фермы. Могут быть некоторые настройки, которые относятся к одной машине, отличной от других машин фермы, которые должны быть отправлены в web.config, но, вероятно, будет множество настроек, которые должны быть одинаковыми по всей ферме , Предполагается, что ферма будет выглядеть как одно приложение снаружи и может пригодиться, если его можно настроить как одну машину. Это означает какой-то общий репозиторий, такой как база данных.
Оцените дополнительный тег, спасибо Andy :) – Rob 2010-12-07 17:05:09