Альтернативы использованию web.config для хранения настроек (для сложных решений)

Question

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

Это создает некоторые проблемы, связанные с настройками.

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

Чтобы решить эту проблему, в некоторых наших недавних проектах мы представили третий проект только для настроек. Мы поместили настройку в систему .Setting файлов ... С помощью простой оболочки, можно было легко добиться различных настроек для различных сред (Dev, QA, Staging, Production и т. Д.).

Единственная проблема заключается в том, что проект настроек (включая класс .Settings) компилируется в сборку, поэтому вы не можете изменить его без выполнения сборки / развертывания, и некоторые наши клиенты хотят иметь возможность конфигурировать свои проекты без Visual Studio.

Итак, есть ли лучшая практика для этого? У меня такое чувство, что я заново изобретаю колесо.

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

РЕДАКТИРОВАТЬ: Оригинальный вопрос не содержал действительно проницательной причины, по которой мы не можем (я думаю) использовать web.config ... Это выводит несколько (очень хороших) ответов из контекста, мой плохой.

Answer 1

System.Configuration.ConfigurationManager.ConnectionStrings и System.Configuration.ConfigurationManager.AppSettings Содержите настройки из исполняемого приложения, чтобы в DAL вы могли получить настройки, хранящиеся в файле web.config.

Для вашей системы вы можете создать пользовательский раздел конфигурации, который будет находиться в вашем файле web.config или в файле потребителя DAL * .config. В этих файлах конфигурации вы можете указать, что они загружаются из отдельного файла конфигурации вашего дизайна и местоположения , Ссылка на внешние файлы конфигурации из Web.Config Как: создать пользовательские разделы конфигурации с помощью ConfigurationSection

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

Answer 2

Похоже, вы не понимаете, как работает web.config / app.config, если я правильно вас читаю. Допустим, у вас есть такая структура:

Проект DAL

Ссылка:

• Некоторые базовые библиотеки
• Разные ссылки

Классы:

• DatabaseHelper
• ObjectClass1
• ObjectClass2
• и т.д ...

Веб-проект

Ссылки

• Некоторые базовые библиотеки
• Проект DAL
• Разные ссылки

Страницы:

• Default.aspx
• и т.д ...
• Web.config

В вашем классе DatabaseHelper вы можете ссылаться на строку подключения следующим образом:

string connString = ConfigurationManager
  .ConnectionStrings["myConnString"]
  .ConnectionString;

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

Следовательно, вам нужен только один файл конфигурации в вашем проекте web / console / winforms / etc ... и вам не нужно беспокоиться о том, чтобы иметь его во время разработки в каждом из ваших проектов библиотеки классов.

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

Answer 3

Вы можете добавить эквивалент к файлу web.config с именем app.config, который компилируется в файл, названный для проекта dll или exe вашего кода. Это полностью изменяемый без перекомпиляции. Вы можете использовать стандартные настройки для строк подключения и различные настройки приложения, которые можно определить в паре ключ / значение - или, немного потрудившись, вы можете определить свой собственный класс и раздел настроек конфигурации. Вы даже можете ссылаться на настройки в конфигурации вашего приложения - чтобы вы могли сохранить 3 настройки в вашем приложении (DEV, QA, PROD), а затем ссылаться только на те, которые вы хотите во время выполнения, в файле app.config. Вот пример того, который был создан для настройки веб-сервиса.

<? Xml version = "1.0" encoding = "utf-8"?>

<{Проект} .Properties.Settings>

{SettingValue}

</ {Проект} .Properties.Settings>




http://docs.oasis -open.org /wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; localName = "UsernameToken" />

Answer 4

Взгляните на Config.Net - простейшая инфраструктура конфигурации для разработчиков .NET .

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

Answer 5

Вы можете сохранить настройки в любом старом XML-файле и использовать XmlSerializer, чтобы взять свой класс и преобразовать его в <-> из Xml. В другом ответе я написал код, который сделал именно это. Связанный ответ сериализует список простых объектов, но он также работает для сериализации одного большого объекта конфигурации.

Поскольку XmlSerializer сериализует в / из общедоступных свойств, если вы не хотите, чтобы значения могли изменяться, вам может потребоваться сделать сам класс неизменным (стиль эскимо) или иметь фасад только для чтения, который находится перед десериализованный.

Это удобный трюк. Вы можете настроить его через ConfigurationManager.AppSettings [] с его собственным разделом конфигурации и ссылками на внешние файлы, или вы можете просто жестко закодировать конкретное имя файла xml для каждого класса конфигурации.

Answer 6

Разделите это. Используйте решение для хранения файлов с фиксированным XML для соединения с базой данных, зашифрованное встроенными функциями шифрования .NET (не сверните свои собственные). Затем, используя полученное соединение с базой данных, найдите свою «таблицу настроек» в базе данных. Таким образом, вы можете изменить настройки без повторного развертывания. Если ваши клиенты должны иметь возможность изменять строку подключения к базе данных без Visual Studio, просто напишите небольшое приложение Windows Forms, которое способно генерировать зашифрованную строку подключения и сохранять файл хранилища с фиксированным XML и, при необходимости, также может подключаться в БД (через тот же файл) и измените таблицу настроек в соответствии с потребностями пользователя.

Answer 7

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

Использование адаптера SQLite ADO потребует только 1 дополнительную DLL в проектах для доступа к настройкам, а сама БД SQLite будет доступна для тех, кто не хочет использовать Visual Studio. Есть даже плагин для Firefox для взаимодействия с базами данных SQLite.

Answer 8

Посмотрите на DslConfig . Кажется, это решает то, что вы ищете.

Answer 9

Если вы используете инфраструктуру DI (например, Unity), вы можете указать аргументы конструктора. Таким образом, гипотетически, ваш поставщик DAL может иметь конструктор, который принимает строку подключения.

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

Answer 10

У вас может быть интерфейс, который отображает ваши настройки, которые используются в вашем DAL. Затем в приложении вы можете просто использовать IoC для передачи настроек в DAL.