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

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

XML:

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML:

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

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

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

Мой любимый сейчас - просто включить Lua, потому что

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

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

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

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

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

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

Но опять же, это более серьезная проблема. Ответ "big" на это, вероятно, включает в себя какую-то матрицу функций или список ситуаций, таких как:

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

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

К чему относится конфигурация?

• Хозяин:
  • Мне нравится YAML в /etc. это переосмыслено в windows?
• Пользователь:
  • Разрешаете ли вы пользователям редактировать конфигурацию с помощью текстового редактора?
  • Должна ли она быть централизованно управляемой? Реестр / gconf / удаленная БД?
  • Может ли пользователь иметь несколько различных профилей ?
• Проект:
  • Файл(ы) в каталоге проекта? (Контроль версий обычно следует этой модели...)

Сложность

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

XML XML XML XML. Здесь мы говорим о файлах конфигурации . Нет "angle bracket tax", если вы не сериализуете объекты в ситуации с высокой производительностью.

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

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

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

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

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

Это все еще говорит мне о XML и почему он все еще является допустимым выбором для конфигурационных файлов (от Тима Брэя ):

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

@Guy

Но конфигурация приложения-это не всегда просто пары ключ / значение. Посмотрите на что-то вроде конфигурации 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" />

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

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

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

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

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

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

@Herms

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

То, что вы часто получаете тогда, также является рекомендуемыми способами, которые они должны/могут быть изменены. Как меню конфигурации в программе или панель конфигурации в приложении "system prefs" (для системных служб программного обеспечения ie). Не позволяя конечным пользователям изменять их непосредственно через RegEdit или NotePad...

Почему?

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

@ninesided

О " выборе библиотеки ", попробуйте связать в (статическая ссылка) любую выбранную библиотеку, чтобы снизить риск попадания в version-conflict-war на компьютерах конечных пользователей.

Если ваш конфигурационный файл-write-once, read-only-at-bootup, а ваши данные-это куча пар значений имен, то лучше всего выбрать тот, который ваш разработчик может начать работать первым.

Если ваши данные немного сложнее, с вложенностью и т. д., Вам, вероятно, лучше использовать 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

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

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

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

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

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

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

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