Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Еще один вариант, если есть много данных, чтобы использовать sqlite3, потому что они права требовать

  • Малый.
  • быстро.
  • Расписание.

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

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

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

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

Количество данных или краткое время выполнения

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

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

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

Сложность

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

Ответ 4

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

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

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

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

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

Ответ 5

@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, будет лучше. Все зависит от набора проблем.

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

@Herms

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

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

Почему?

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

@ninesided

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

[1] System.Configuration Namespace - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

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

Ответ 12

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

Ответ 13

Re: epatel comment

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

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

Ответ 14

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

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

Ответ 15

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

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