Здравствуйте, Sinix, Вы писали:
S>Могу. Типовая задача — часть настроек должны задаваться администратором, часть из них может переопределяться пользователями. Решается хранением настроек в общей базе + прослойкой из view/sp, которые отдают настройки для текущего поользователя.
Такое у нас тоже есть, настройки берутся через вызов сервиса и дальше мы делаем с ними все, что захотим.
Здравствуйте, Аноним, Вы писали:
А>Понятно, спасибо. Короче то, что редко менчется. У нас для простоты это просто в app.config
Еще бывают настройки, общие для всех версий приложения, и настройки, специфичные для определенной версии. Это тоже можно с определенной натяжкой назвать глобальными/локальными.
Здравствуйте, Sinix, Вы писали:
S>А, тогда всё действительно просто. А вот когда надо управлять настройкамии как политикой, сохранять только фактически изменённые настроки или менять провайдеров — вот тут проще не переизобретать своё.
Расскажите, что дает стандартный механизм в плане управления настройками как политикой? Вот можно ли например сделать, чтобы для одних настроек приоритетнее было локальное значение, а для других глобальное?
I>Расскажите, что дает стандартный механизм в плане управления настройками как политикой? Вот можно ли например сделать, чтобы для одних настроек приоритетнее было локальное значение, а для других глобальное?
Ничего особого, просто он достаточно продуман, чтобы скрыть кучу подобных нюансов под капотом — за приоритет отвечает провайдер, точнее, слой в СУБД. Ну и можно использовать scope = Application для системных настроек.
