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

https://stackoverflow.com/questions/12144

08-06-2019
|

Вопрос

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

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

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

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

Решение

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">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

Первый:Это действительно серьезный дискуссионный вопрос, а не быстрые вопросы и ответы.

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

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

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

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

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

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

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

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

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

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

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

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

Сложность

Существует ли только несколько плоских значений?Рассмотрим 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 делает его очень простым в использовании.Изначально Nini был разработан для .NET, но был портирован на другие платформы с использованием Mono.

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

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

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

@Herms

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

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

Почему?

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

@ninesided (девять сторон )

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

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

Если ваши данные немного сложнее, с вложенностью и т.д., вам, вероятно, лучше использовать 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] Система.Пространство имен конфигурации - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow