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

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

На данный момент большая часть нашего кода - это Java, поэтому мы изучали Apache Commons Config , но обнаружили, что он довольно подробный. Мы также посмотрели на XMLBeans , но, похоже, здесь много возни. Я также чувствую, что меня подталкивают к XML как формату, но мои клиенты и коллеги опасаются попробовать что-то еще. Я могу понять это с точки зрения клиента, все слышали об XML, но, в конце концов, не следует ли использовать правильный инструмент для работы?

Какие форматы и библиотеки сегодня используют в производственных системах, пытается ли кто-нибудь еще избежать налога на угловые скобки?

Изменить: действительно должно быть кроссплатформенное решение: Linux, Windows, Solaris и т. Д., И выбор библиотеки, используемой для взаимодействия с файлами конфигурации, так же важен, как и выбор формата.

Ответов (15)

Решение

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

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

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

Насколько мне известно, реестр 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

@Парень

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

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

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

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

@Herms

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

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

Почему?

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

@ninesided

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

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

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

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

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

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

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

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

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

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

Re: комментарий эпателя

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

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

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

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

Мы используем файлы свойств просто потому, что Java изначально поддерживает их. Пару месяцев назад я увидел, что SpringSource Application Platform использует JSON для настройки своего сервера, и это выглядит очень интересно. Я сравнил различные обозначения конфигурации и пришел к выводу, что на данный момент лучше всего подходит 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.)
  • проще переключиться на другой db, ODBC, что угодно. (чем это из fugly-файла)

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

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

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

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

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

Сложность

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

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

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

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

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

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

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