Файлы конфигурации приложения

XML XML XML XML. Мы говорим об файлах конфигурации. Не существует «налога на угловые скобки», если вы не сериализуете объекты в ситуации с высокой производительностью.

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

Если в вашем магазине есть люди, которые боятся этой новомодной технологии XML, мне вас жаль.

YAML по той простой причине, что он делает файлы конфигурации более читабельными по сравнению с XML.

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">[email protected]</address>
    <address password="xxxx">[email protected]</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: [email protected]
              password: xxxx
            - address: [email protected]
              password: xxxx

Примеры взяты с этой страницы: http://www.kuro5hin.org/story/2004/10/29/14225/062

Во-первых: это действительно большой вопрос для обсуждения, а не быстрый вопрос + ответ.

Сейчас мне больше всего нравится просто включать Lua, потому что

• Я могу разрешить такие вещи, как ширина = высота * (1 + 1/3)
• Я могу сделать доступными пользовательские функции
• Я могу запретить что-нибудь еще. (невозможно, например, в Python (включая соленья).)
• Я, вероятно, все равно захочу скриптовый язык где-то еще в проекте.

Другой вариант, если данных много, — использовать sqlite3, потому что они правы

• Маленький.
• Быстро.
• Надежный.

Выберите любые три.

К чему я хотел бы добавить:

• резервные копии - это несложно. (просто скопируйте файл db.)
• проще переключиться на другую БД, ODBC, что угодно. (чем из fugly-файла)

Но опять же, это большая проблема. «Большой» ответ на это, вероятно, включает в себя какую-то матрицу функций или список ситуаций, таких как:

Объем данных или короткое время выполнения

• Для больших объемов данных вам может понадобиться эффективное хранилище, например db.
• Для коротких прогонов (часто) вам может понадобиться что-то, для чего вам не нужно много анализировать, рассмотрите что-то, что можно напрямую mmap:ed.

С чем связана конфигурация?

• Host:
  • I like YAML in /etc. Is that reimplemented in windows?
• User:
  • Do you permit users to edit config with text editor?
  • Должен ли он быть централизованно управляемым? Реестр/gconf/удаленная БД?
  • Может ли у пользователя быть несколько разных профилей?
• Project:
  • File(s) in project directory? (Version control usually follows this model...)

Сложность

• Есть только несколько плоских значений? Рассмотрим YAML.
• Являются ли данные вложенными или зависимыми каким-то образом? (Вот тут становится интересно.)
• Может быть желательной функцией, позволяющей использовать скрипты в той или иной форме?
• Шаблоны можно рассматривать как своего рода конфигурационные файлы.

Не начав новую священную войну, я главным образом не согласен с Джеффом в отношении поста о налоге на угловые скобки. В XML нет ничего плохого, он достаточно удобочитаем для человека (настолько же, насколько файлы YAML, JSON или INI), но помните, что он предназначен для чтения машинами. Большинство комбинаций язык/фреймворк поставляются с тем или иным бесплатным синтаксическим анализатором XML, что делает XML довольно хорошим выбором.

Кроме того, если вы используете хорошую IDE, такую ​​​​как Visual Studio, и если XML поставляется со схемой, вы можете передать схему VS и волшебным образом получить intellisense (например, вы можете получить ее для NHibernate).

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

Это по-прежнему говорит мне все о XML и о том, почему он по-прежнему допустим для файлов конфигурации (из Тим Брей):

"Если вы хотите предоставить данные общего назначения, с которыми получатель может захотеть сделать непредвиденные странные и сумасшедшие вещи, или если вы хотите быть действительно параноиком и разборчивым в отношении i18n, или если то, что вы отправляете, больше похоже на документ, чем структура, или если порядок данных имеет значение, или если данные потенциально долгоживущие (например, более секунд), XML - это путь. Мне также кажется, что комбинация XML и XPath идеально подходит для форматов данных, которые должны быть расширяемыми, иными словами, довольно легко написать код обработки XML, который не даст сбой при наличии изменений в формате сообщения, которые не касаются той части, которую вы используете. заботиться о."

@Парень

Но конфигурация приложения — это не всегда просто пары ключ/значение. Посмотрите что-то вроде конфигурации tomcat, какие порты он прослушивает. Вот пример:

    <Connector port="80" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />


    <Connector port="8009" 
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

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

Если конфигурация вашего приложения проста, то, вероятно, подойдет что-то простое, например файл INI, который считывается в словарь. Но для чего-то более сложного, такого как конфигурация сервера, INI-файл было бы очень сложно поддерживать, и что-то более структурированное, например XML или YAML, было бы лучше. Все зависит от поставленной задачи.

Мы используем конфигурационные файлы в стиле ini. Для управления ими мы используем библиотеку Nini. Нини делает его очень простым в использовании. Изначально Nini предназначалась для .NET, но была перенесена на другие платформы с использованием Mono.

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

Там, где я работаю, мы в основном используем XML, и я не могу поверить, что файл конфигурации, загруженный в кэш как объекты при первом чтении или после того, как в него была записана информация, а затем абстрагированный от остальной части программы, на самом деле так уж важен. это не ударит ни по ЦП, ни по дисковому пространству.
И это также довольно читабельно, если вы правильно структурируете файл.

И все языки на всех платформах поддерживают XML через довольно распространенные библиотеки.

@Гермс

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

То, что вы часто получаете, это также рекомендуемые способы их изменения. Подобно меню конфигурации в программе или панели конфигурации в приложении «системные настройки» (например, для программного обеспечения системных служб). Не позволять конечным пользователям изменять их напрямую через RegEdit или NotePad...

Почему?

1. Конечные пользователи (=клиенты) привыкли к своим платформам
2. Система резервного копирования может лучше сохранять «безопасные настройки» и т. д.

@девятисторонний

Что касается « выбора библиотеки », попробуйте связать (статическую ссылку) любую выбранную библиотеку, чтобы снизить риск конфликта версий на компьютерах конечных пользователей.

Если ваш конфигурационный файл поддерживает однократную запись и только чтение при загрузке, а ваши данные представляют собой набор пар «имя-значение», лучшим выбором будет тот, который ваш разработчик может заставить работать первым.

Если ваши данные немного сложнее, с вложенностью и т. д., вам, вероятно, лучше использовать YAML, XML или SQLite.

Если вам нужны вложенные данные и/или возможность запрашивать данные конфигурации после загрузки, используйте XML или SQLite. Оба имеют довольно хорошие языки запросов (XPATH и SQL) для структурированных/вложенных данных.

Если ваши данные конфигурации сильно нормализованы (например, 5-я нормальная форма), вам лучше использовать SQLite, потому что SQL лучше подходит для работы с сильно нормализованными данными.

Если вы планируете писать в набор данных конфигурации во время работы программы, то вам лучше использовать SQLite. Например, если вы загружаете данные конфигурации с другого компьютера или если вы основываете будущие решения о выполнении программы на данных, собранных при предыдущем выполнении программы. SQLite реализует очень надежный механизм хранения данных, который чрезвычайно сложно повредить при отключении электроэнергии или программах, которые зависают в несогласованном состоянии из-за ошибок. Поврежденные данные приводят к высоким затратам на поддержку на месте, и SQLite будет работать намного лучше, чем любое собственное решение или даже популярные библиотеки на основе XML или YAML.

Посетите мою страницу для получения дополнительной информации о SQLite.

Насколько мне известно, реестр Windows больше не является предпочтительным способом хранения конфигурации, если вы используете .NET — большинство приложений теперь используют System.Configuration [1, 2]. Поскольку это также основано на XML, кажется, что все движется в направлении использования XML для конфигурации.

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

Что касается налога на угловые скобки - я не слишком беспокоюсь об этом, поскольку библиотеки XML позаботятся об его абстрагировании. Единственный раз, когда это может быть соображением, - это если у вас очень мало места для работы и каждый байт имеет значение.

[1] Пространство имен System.Configuration — http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Использование файлов конфигурации приложений в .NET — http://www.developer.com/net/net/article.php/3396111

Мы используем файлы свойств просто потому, что Java изначально поддерживает их. Пару месяцев назад я увидел, что SpringSource Application Platform использует JSON для настройки своего сервера, и это выглядит очень интересно. Я сравнил различные нотации конфигурации и пришел к выводу, что XML, по-видимому, быть лучшим на данный момент. Он имеет хорошую поддержку инструментов и довольно независим от платформы.

Re: комментарий epatel

Я думаю, что первоначальный вопрос касался конфигурации приложения, которую будет выполнять администратор, а не только сохранения пользовательских настроек. Предложения, которые вы дали, кажутся больше для пользовательских настроек, чем для конфигурации приложения, и обычно это не то, с чем пользователь когда-либо будет иметь дело напрямую (приложение должно предоставлять параметры конфигурации в пользовательском интерфейсе, а затем обновлять файлы). Я действительно надеюсь, что вы никогда не заставите пользователя просматривать/редактировать реестр. :)

Что касается самого вопроса, я бы сказал, что с XML, вероятно, все в порядке, так как многие люди привыкли использовать его для настройки. Пока вы упорядочиваете значения конфигурации простым в использовании способом, «налог на угловую скобку» не должен быть слишком плохим.

Может быть, это немного тангенциально, но я считаю, что файл конфигурации должен быть прочитан в словарь/хеш-таблицу значений ключа при первом запуске приложения и с тех пор всегда доступен через этот объект для скорости. Обычно таблица ключ/значение начинается как строка в строку, но вспомогательные функции в объекте делают такие вещи, как DateTime GetConfigDate (строковый ключ) и т. д.

Я думаю, что важно только выбрать формат, который вы предпочитаете и можете быстро ориентироваться. XML и JSON — прекрасные форматы для конфигураций, и они широко поддерживаются — мне кажется, что техническая реализация не является сутью проблемы. Это на 100% то, что облегчает вам задачу с конфигурационными файлами.

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

На какой платформе вы работаете? Я бы рекомендовал попробовать использовать для этого предпочтительный/общий метод.

1. MacOSX — списки
2. Win32 - Реестр (или здесь есть новый, давно я на нем разрабатывал)
3. Linux/Unix - ~/.apprc (возможно, имя-значение)