Вопрос скорее по архитектуре: мы пишем приложение у которого есть некие настройки (Options/Settings)
Есть сооотвествующие меню и диалоговые окна.
Вопросы:
Как вы такие объекты (Options/Settings) храните, сохраняете, читаете?
Есть ли стандартные механизмы в .NET WinForms?
Как к таким объектам происходит доступ из любой точки приложения, из любого проекта — т.е. они должны быть видисы отовсюда.
Здравствуйте, Аноним, Вы писали:
А>Вопрос скорее по архитектуре: мы пишем приложение у которого есть некие настройки (Options/Settings) А>Есть сооотвествующие меню и диалоговые окна.
А>Вопросы: А>Как вы такие объекты (Options/Settings) храните, сохраняете, читаете? А>Есть ли стандартные механизмы в .NET WinForms? А>Как к таким объектам происходит доступ из любой точки приложения, из любого проекта — т.е. они должны быть видисы отовсюда.
А>Спасибо
Сделай класс настроек, сохраняй куда тебе угодно XmlSerializer'ом (например в AppSettings/AppName), куда уж проще. Встроенными механизмами лучше не пользоваться, ибо они недостаточно гибкие.
Здравствуйте, Andy77, Вы писали:
A>Сделай класс настроек, сохраняй куда тебе угодно XmlSerializer'ом (например в AppSettings/AppName), куда уж проще. Встроенными механизмами лучше не пользоваться, ибо они недостаточно гибкие.
Здравствуйте, Аноним, Вы писали:
А>что такое AppSettings/AppName?
Я имел в виду Application Data, который обычно находится в "C:\Documents and Settings\username\Application Data\". Чтобы получить путь программно — Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Здравствуйте, Sinix, Вы писали:
S>Ответ на все 3: cтандартные settings, по желанию — дополняем своим SettingsProvider.
Я, если честно, до сих пор не понимаю смысла в существовании этого механизма. Пробовал его использовать, наткнулся на дурацкие ограничения и не получил никаких преимуществ, забыл о его существовании. Сохранение настроек у нас и так реализовано проще некуда — одна строчка xml-сериализации, при том, что приложение очень большое и сложное — есть глобальные настройки, настройки пользователя, настройки, специфичные для версии, разные версии плагинов и т.д. Баловство какое-то этот SettingsProvider, по-моему.
Здравствуйте, Sinix, Вы писали:
A>>Я, если честно, до сих пор не понимаю смысла в существовании этого механизма.
S>Оно простое, оно уже реализовано и более-менее работает. Если делать что-то своё, придётся переизобретать кучу вещей.
S>Кстати, как вам удаётся сохранять и локальные и глобальные настройки одной строчкой?
Что такое локальные и что такое глобальные настройки?
Здравствуйте, Аноним, Вы писали:
А>Что такое локальные и что такое глобальные настройки?
Сохранение настроек у нас и так реализовано проще некуда — одна строчка xml-сериализации, при том, что приложение очень большое и сложное — есть глобальные настройки, настройки пользователя (=локальные — Sinix)
...
Здравствуйте, Sinix, Вы писали:
S>Оно простое, оно уже реализовано и более-менее работает. Если делать что-то своё, придётся переизобретать кучу вещей.
Да там же шаг влево, шаг вправо — и расстрел А что придется переизобретать, кстати? У нас все сделано "в лоб", абсолютно просто и предсказуемо. Может, я что-то пропустил и даже об этом не догадываюсь?
S>Кстати, как вам удаётся сохранять и локальные и глобальные настройки одной строчкой?
Да это я уже заговариваюсь, нет у нас никаких локальных-глобальных, точнее, есть настройки, специфичные для всех версий плагина и отдельно для каждой версии. В основном сохранение-чтение выливается в один вызов хелпера XmlUtils.Serialize(AppFolders.GetPluginDataFolder("PowerPack"), GetSettings()). Куда уж проще?
S>Сохранение настроек у нас и так реализовано проще некуда — одна строчка xml-сериализации, при том, что приложение очень большое и сложное — есть глобальные настройки, настройки пользователя (=локальные — Sinix)
S>...
О, точно, есть у нас и глобальные настройки, а я уже успел забыть за полчаса, спасибо за напоминание, Sinix! Всё, пора идти спать
Здравствуйте, Andy77, Вы писали:
A>Да это я уже заговариваюсь, нет у нас никаких локальных-глобальных, точнее, есть настройки, специфичные для всех версий плагина и отдельно для каждой версии. В основном сохранение-чтение выливается в один вызов хелпера
XmlUtils.Serialize(AppFolders.GetPluginDataFolder("PowerPack"), GetSettings()). Куда уж проще?
А, тогда всё действительно просто. А вот когда надо управлять настройкамии как политикой, сохранять только фактически изменённые настроки или менять провайдеров — вот тут проще не переизобретать своё.
Здравствуйте, Sinix, Вы писали:
S>А, тогда всё действительно просто. А вот когда надо управлять настройкамии как политикой, сохранять только фактически изменённые настроки или менять провайдеров — вот тут проще не переизобретать своё.
А зачем оно ? Можно примеров из практики ? Работаем как и предыдущий оратор — никаких проблем, а с подходом от MS — полный рот.
Здравствуйте, Sinix, Вы писали:
S>А, тогда всё действительно просто. А вот когда надо управлять настройкамии как политикой, сохранять только фактически изменённые настроки или менять провайдеров — вот тут проще не переизобретать своё.
Сохранять только фактически измененные настройки мы умеем, написали хелпер, который через рефлекшн сравнивает настройки с эталоном. Это всё равно полезная была вещь, которая и в других местах применяется. А с управлением настройками как политикой, к счастью, нам связываться не приходилось. Ты с этим сталкивался? Можешь привести пример?
В общем, я думаю, для обычного десктоп-приложения, как у автора, за глаза хватает xml-сериализатора. Править легко, кодировать легко, мигрировать легко, файловой системой все умеют пользоваться, полная свобода действий.
Здравствуйте, Andy77, Вы писали:
A> А с управлением настройками как политикой, к счастью, нам связываться не приходилось. Ты с этим сталкивался? Можешь привести пример?
Могу. Типовая задача — часть настроек должны задаваться администратором, часть из них может переопределяться пользователями. Решается хранением настроек в общей базе + прослойкой из view/sp, которые отдают настройки для текущего поользователя.
S>Сохранение настроек у нас и так реализовано проще некуда — одна строчка xml-сериализации, при том, что приложение очень большое и сложное — есть глобальные настройки, настройки пользователя (=локальные — Sinix)
S>...
Ты можешь пример привести?
у нам все настройки — настройки пользователя. Что такое "глобальные настройки"? То, что в app.config сидит?
Ты можешь привести пример?
Здравствуйте, Аноним, Вы писали:
А>у нам все настройки — настройки пользователя. Что такое "глобальные настройки"? То, что в app.config сидит?
Грубо говоря, настройки, определяемые разработчиками/администратором.
А>Ты можешь привести пример?
Неа Слишком специфичные примеры в основном. Если брать что-то универсальное,то это будут адреса серверов, таймауты, имена временных папок, настройки трассировки и т.д и т.п.
А>>у нам все настройки — настройки пользователя. Что такое "глобальные настройки"? То, что в app.config сидит? S>Грубо говоря, настройки, определяемые разработчиками/администратором.
А>>Ты можешь привести пример? S>Неа Слишком специфичные примеры в основном. Если брать что-то универсальное,то это будут адреса серверов, таймауты, имена временных папок, настройки трассировки и т.д и т.п.
Понятно, спасибо. Короче то, что редко менчется. У нас для простоты это просто в app.config
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>А зачем оно ? Побочный артифакт от MVVM и прочих binding-архитектур ?
Нет (к слову, не скажу, что я фанат MVVM). Покажу на примере spreadsheet — зачастую приходится мержить настройки, определенные пользователем для всей колонки (часть этих настроек — цвет фона), с настройками, определенными для определенной ячейки; в этом случае настройки ячейки имеют приоритет. Легче всего этого добиться, сохраняя в ячейке только измененные настройки.
А что придется переизобретать, кстати? У нас все сделано "в лоб", абсолютно просто и предсказуемо. Может, я что-то пропустил и даже об этом не догадываюсь?
