Добрый день
Подскажите плиз как лучше всего работать с файлом web.config (а скорее всего с любым config) в ситуации когда у меня много сборок. Значения из web.config бывают нужны на разных уровнях приложения и в UI и в DAL (connection string) при этом не очень хочется использовать ConfigurationManager.AppSettings[key].

Здравствуйте, Аноним, Вы писали:

А>Значения из web.config бывают нужны на разных уровнях приложения и в UI и в DAL (connection string) при этом не очень хочется использовать ConfigurationManager.AppSettings[key].

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день
А>Подскажите плиз как лучше всего работать с файлом web.config (а скорее всего с любым config) в ситуации когда у меня много сборок. Значения из web.config бывают нужны на разных уровнях приложения и в UI и в DAL (connection string) при этом не очень хочется использовать ConfigurationManager.AppSettings[key].
А чем плохо его использовать? Почему не хочется?

Здравствуйте, vmpire, Вы писали:

А>>Подскажите плиз как лучше всего работать с файлом web.config (а скорее всего с любым config) в ситуации когда у меня много сборок. Значения из web.config бывают нужны на разных уровнях приложения и в UI и в DAL (connection string) при этом не очень хочется использовать ConfigurationManager.AppSettings[key].
V>А чем плохо его использовать? Почему не хочется?

У меня часто значения из web.config связанные с некоторой логикой (проверка задан ключ или нет, парсинг для int полей т.д.) если использовать ConfigurationManager.AppSettings[key] то эту логику придется дублировать.

Здравствуйте, Аноним, Вы писали:

А>Добрый день
А>Подскажите плиз как лучше всего работать с файлом web.config (а скорее всего с любым config) в ситуации когда у меня много сборок. Значения из web.config бывают нужны на разных уровнях приложения и в UI и в DAL (connection string) при этом не очень хочется использовать ConfigurationManager.AppSettings[key].

Спонтанно родилось следующее решение:

в самой абстрактной сборке вводим public class AppConfig
в каждой сборке, которая требует настроек (constr, путь к файлам, ссылки (url) на внешние системы, какие-то имена пользователей, emailы) мы создаем собственный класс AppConfigExt. В этом файле мы реализуем методы (extension) читающие всю необходимую (для конкретной сборки) информацию из ConfigurationManager.AppSettings или вызывающие подобные методы из базового AppConfig (например добавлено бросания exception если нет данных в .config файле).

В результате, нам достаточно в любой момент (в любой сборке) создать объект AppConfig и мы получаем доступ ко всей инфраструктуре конфигурации (а это не только ключи config файла, но и возможно бизнес логика их обработки) для текущей сборки.

Здравствуйте, Qbit86, Вы писали:

Q>Глубокие уровни приложения должны брать настройки не из конфигов, а получать их от вызывающей стороны (например, настройки могут внедряться через параметры конструкторов).

Если того требует уровень абстракции, то конечно. Но когда этого не требуется, то имхо лучше уйти в сторону "соглашения вместо настроек".