Pull to refresh

Comments 15

Хорошая статья. Можно также упомянуть про более альтернативный подход — это интерфейс IConfigurationSectionHandler, который позволяет парсить секции вручную
… каковой подход MS не рекомендует.
… на сама использует (убедился, когда смотрел system.dll)
А вы думаете, что MS должны были переписать весь фреймворк с появление configurationelement? Legacy code такой legacy.
ИМХО, писать из кода в app.exe.config я буду только в ну уж очень крайних случаях. Стараюсь пользоваться правилом — не писать в директорию из которой пользователь имеет права на запуск приложений. Лучше создам еще одну директорию в папке программы и там буду хранить свой app.config.xml. Ну а для user-specific параметров — стараюсь использовать user.config. Как-то так…
Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам. От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных по двум причинам: 1 — хорошая расширяемость, 2 — удобство редактирования при достаточно сложной конфигурации (косвенно вытекает из пункта 1). Хотя, если приложение достаточно небольшое и/или не подразумевает расширяемость и/или имеет короткосрочный этап разработки, в некоторых случаях файлы будут проще.
«Правило неоднозначное, можно ведь настроить ACL на запись только на допустимый файл конфигурации, исключая несанкционированный доступ к защищенным объектам.»
Слишком геморройно. А еще при многопользовательской конфигурации не работает.

«От себя добавлю, держать перезаписываемую конфигурацию удобнее в базе данных»
То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?
Слишком геморройно. А еще при многопользовательской конфигурации не работает.
Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.

То есть когда мы ставим пользователю локальное приложение, нам ему еще и базу данных надо поставить, даже если оно ее не использует?
Во-первых, приложение будет использовать БД, так как в ней будет храниться конфигурация. Во-вторых, не обязательно использовать сервер БД, для простого приложения может быть достаточно SQL Server Compact или SQLite — получаем те же удобства конфигурирования на гибких условиях. В-третьих, последним предложением я подчеркнул, что все зависит от случая и использование базы не всегда будет эффективным.
«Это настолько же возможно (в том числе при многопользовательской конфигурации) и с теми же затратами, насколько при работе с отдельными папками конфигураций.»
Отнюдь. Когда в приложении настройки делятся на app-level и user-level, .net автоматически распихивает последние по папкам пользователей, куда у приложения есть права на запись (а в program files, куда оно ставится, по умолчанию прав нет). Так что zero effort.
User-level конфигурацию, разумеется, удобнее и следует держать в папке профиля пользователя, возможно, я внес недопонимание, не упомянув, что говорю о глобальных настройках. Эта фрагментация, к слову, — еще одна причина, по которой использование базы данных является более удобным.
UFO just landed and posted this here
Спасибо, все придумано до нас оказывается )
Сильно! Особенно хорошо дополнение к студии.
Таки проще сериализацию использовать имхо. Гуглится Xml Serialization configuration Section на два клика — один раз написал\скопипастил и «на всю жизнь».
Интересно, спасибо. Попробовал сам с app.config поиграться, вот только беде при закрытие программы все что было записано app.config сбрасывается в первоначальное состояние.
Sign up to leave a comment.

Articles