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

голоса
37

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

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

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

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

Задан 15/08/2008 в 12:19
источник пользователем
На других языках...                            


15 ответов

голоса
27

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

Ответил 15/08/2008 в 15:17
источник пользователем

голоса
14

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

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

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

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

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

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

На что я хотел бы добавить:

  • резервное копирование несложно. (Просто скопировать файл базы данных.)
  • легче переключиться на другую БД, ODBC, что угодно. (Чем из Fugly-файла)

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

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

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

Что конфигурация относится к?

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

сложность

  • Есть только несколько плоских ценностей? Рассмотрим YAML.
  • Вложен данные, или зависит каким-то образом? (Это становится интересно.)
  • Может это быть желательным признаком, чтобы позволить той или иной форме сценариев?
  • Шаблоны можно рассматривать как своего рода файлов конфигурации ..
Ответил 15/08/2008 в 16:19
источник пользователем

голоса
10

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

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

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

Ответил 15/08/2008 в 14:45
источник пользователем

голоса
9

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

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

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

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

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

Ответил 15/08/2008 в 13:24
источник пользователем

голоса
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" />

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

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

Ответил 15/08/2008 в 21:26
источник пользователем

голоса
2

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

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

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

Ответил 15/08/2008 в 15:26
источник пользователем

голоса
2

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

Ответил 15/08/2008 в 13:41
источник пользователем

голоса
1

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

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

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

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

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

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

Ответил 19/05/2009 в 17:40
источник пользователем

голоса
1

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

Ответил 15/08/2008 в 16:23
источник пользователем

голоса
1

@Herms

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

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

Зачем?

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

@ninesided

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

Ответил 15/08/2008 в 14:58
источник пользователем

голоса
0

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

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

Ответил 13/11/2012 в 18:54
источник пользователем

голоса
0

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

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

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

Ответил 15/08/2008 в 14:18
источник пользователем

голоса
0

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

Ответил 15/08/2008 в 13:32
источник пользователем

голоса
0

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

Ответил 15/08/2008 в 13:04
источник пользователем

голоса
-3

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

  1. MacOSX - plists
  2. Win32 - Registry (или есть новый один здесь, давно я разработал на него)
  3. Linux / Unix - ~ / .apprc (имя-значение может быть)
Ответил 15/08/2008 в 12:27
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more