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

Question

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

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

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

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

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

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

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

EDIT: Исходный вопрос не содержит действительно проникающей причины, по которой мы не можем (я думаю) использовать web.config ... Это дает несколько (очень хороших) ответов из контекста, мое плохое.

Answer 1

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

Answer 2

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

Для вашей системы вы можете создать настраиваемый раздел конфигурации, который будет находиться в вашем файле web.config или в вашем файле * .config вашего DAL. В этих файлах конфигурации вы можете указать, что они загружаются из отдельного файла конфигурации вашего дизайна и место нахождения. Referencing external config files from Web.Config How to: Create Custom Configuration Sections Using ConfigurationSection

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

Answer 3

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

Answer 4

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

<? Xml version = " 1.0 " encoding = " utf-8 "? >
< конфигурации >
    <configSections>
        < sectionGroup имя = " applicationSettings " типа = " System.Configuration.ApplicationSettingsGroup, система, Version = 2.0.0.0, культура = нейтральной, PublicKeyToken = b77a5c561934e089 " >
            < раздел имя = " {Проект} .Properties.Settings " тип = " System.Configuration.ClientSettingsSection, System, Version = 2.0.0.0, культура = нейтральной, PublicKeyToken = b77a5c561934e089 " requirePermission = " ложь "/>
        </sectionGroup >
        < секции имя = " microsoft.web.services3 " тип = " Microsoft.Web.Services3.Configuration.WebServicesConfiguration, Microsoft.Web.Services3, Version = 3.0.0.0, культура = нейтральной, PublicKeyToken = 31bf3856ad364e35 "/>
    </configSections >
    <applicationSettings>
        < {Проект} .Properties.Settings >
            < Имя параметра = " {SettingName} " serializeAs = " Строка " >
                < значение > {SettingValue} </значение >
            </установка >
        < /{Project}.Properties.Settings >
    </applicationSettings >
    < microsoft.web.Услуги3 >
        < безопасности >
            <securityTokenManager>
                < типа добавь = " Microsoft.Web.Services3.Security.Tokens.UsernameTokenManager, Microsoft .Web.Services3, Ver sion = 3.0.0.0, Культура = нейтральная, PublicKeyToken = 31bf3856ad364e35 " namespace = " http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; LocalName = " UsernameToken "/>
            </securityTokenManager >
        </безопасность >
    </microsoft.web.services3>
</конфигурации >

Answer 5

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

Использование SQLite ADO adapter потребует только одной дополнительной библиотеки DLL в проектах для доступа к настройкам, а сам SQLite DB будет доступен для тех людей, которые не хотят использовать Visual Studio. Существует даже плагин для взаимодействия Firefox с базами данных SQLite.

Answer 6

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

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

Answer 7

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

DAL Проект

Ссылки:

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

Классы:

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

Web Project

Ссылки:

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

Страницы:

• Default.aspx
• SomePage1.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 8

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

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

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

Answer 9

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