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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, "Если Вы хотите обеспечить данные общего назначения, что получатель мог бы хотеть сделать непредвиденные странные и сумасшедшие вещи с, или если Вы хотите быть действительно параноиками и требовательными в отношении i18n, или если, какая отправка you’re больше похожа на документ, чем структура, или если порядок вопросов данных, или если данные потенциально долговечны (как в, больше, чем секунды) XML, является способом пойти. Мне также кажется, что комбинация XML и XPath поражает зону наилучшего восприятия для форматов данных, которые должны быть расширяемы; то есть it’s, довольно легкий записать код обработки XML, который won’t приводят к сбою в присутствии изменений в формате сообщения, что don’t касаются части, о которой Вы заботитесь".

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

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

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, потому что они правы к Маленькому заявлению

• .
• Быстро.
• Надежный.

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

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

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

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

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

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

, Что реализовывает конфигурацию, касаются?

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

, Сложность

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

конфигурация @Guy

Но приложения является не всегда просто парами ключ/значение. Посмотрите на что-то как конфигурация кота для того, на каких портах она слушает. Вот пример:

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

@Herms

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

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

, Почему?

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

@ninesided

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