应用程序配置文件 [关闭]答案

【问题标题】：Application configuration files [closed]应用程序配置文件 [关闭]
【发布时间】：2010-09-05 22:39:02
【问题描述】：

好的，所以我不想在这里开始一场圣战，但是我们正在尝试整合我们处理应用程序配置文件的方式，并且我们正在努力做出最好的决定采取的方法。目前，我们分发的每个应用程序都使用它自己的临时配置文件，无论是属性文件（ini 样式）、XML 还是 JSON（目前仅供内部使用！）。

目前我们的大部分代码都是 Java，所以我们一直在查看 Apache Commons Config，但我们发现它非常冗长。我们还查看了XMLBeans，但它似乎有很多东西。我也觉得好像我正被推向将 XML 作为一种格式，但我的客户和同事对尝试其他东西感到担忧。我可以从客户的角度理解它，每个人都听说过 XML，但归根结底，不应该使用正确的工具来完成这项工作吗？

现在人们在生产系统中使用什么格式和库，还有其他人试图避免angle bracket tax吗？

编辑： 确实需要一个跨平台解决方案：Linux、Windows、Solaris 等，用于与配置文件接口的库的选择同样重要作为格式的选择。

【问题讨论】：

只是因为说 XMLBeans“看起来很无聊”而被投票赞成

标签： java xml json cross-platform configuration-files

【解决方案1】：

如果您的配置文件是一次写入、启动时只读，并且您的数据是一堆名称值对，那么您的最佳选择是开发人员可以首先开始工作的那个。

如果你的数据有点复杂，比如嵌套等，你最好使用 YAML、XML 或 SQLite。

如果您需要嵌套数据和/或启动后查询配置数据的能力，请使用 XML 或 SQLite。两者都有很好的结构化/嵌套数据查询语言（XPATH 和 SQL）。

如果您的配置数据是高度规范化的（例如第五范式），您最好使用 SQLite，因为 SQL 更适合处理高度规范化的数据。

如果您打算在程序运行期间写入配置数据集，那么您最好使用 SQLite。例如，如果您正在从另一台计算机下载配置数据，或者如果您正在根据先前程序执行中收集的数据做出未来的程序执行决策。 SQLite 实现了一个非常强大的数据存储引擎，当您遇到停电或由于错误而处于不一致状态的程序挂起时，该引擎极难损坏。损坏的数据会导致高昂的现场支持成本，而 SQLite 将比任何本土解决方案甚至围绕 XML 或 YAML 的流行库做得更好。

Check out my page 了解有关 SQLite 的更多信息。

【讨论】：

【解决方案2】：

我认为唯一重要的是选择您喜欢的格式并且可以快速导航。 XML 和 JSON 都是很好的配置格式，并且得到了广泛的支持——我认为，技术实现并不是问题的关键。这是 100% 让您更轻松地完成配置文件任务的原因。

我已经开始使用 JSON，因为我经常使用它作为一种数据传输格式，并且序列化程序可以轻松加载到任何开发框架中。我发现 JSON 比 XML 更容易阅读，这使得处理多个服务，每个服务都使用一个经常修改的配置文件，这对我来说更容易！

【讨论】：

【解决方案3】：

XML XML XML XML。我们在这里讨论的是配置文件。如果您不在性能密集型情况下序列化对象，则没有“尖括号税”。

除了机器可读之外，配置文件还必须是人类可读且易于理解的。 XML 是两者之间的良好折衷。

如果您的商店里有人害怕这种新奇的 XML 技术，我为您感到难过。

【讨论】：

不确定是不是讽刺，但鉴于答案是 9 岁，我想不是。 :)
那是一个不同的时代......

【解决方案4】：

@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 这样更结构化的东西会更好。这完全取决于问题集。

【讨论】：

【解决方案5】：

这里可能有点切题，但我认为配置文件应该在应用程序首次启动时读入键值字典/哈希表，并且从那时起始终通过此对象访问以提高速度。通常，键/值表以字符串到字符串的形式开始，但对象中的辅助函数会执行 DateTime GetConfigDate(string key) 等操作...

【讨论】：

【解决方案6】：

首先：这是一个非常大的辩论问题，而不是快速问答。

我现在最喜欢的是简单地包含Lua，因为

我可以允许 width=height*(1+1/3) 之类的东西
我可以提供自定义函数
我可以禁止其他任何事情。（例如，在 Python（包括泡菜）中是不可能的。）
无论如何，我可能会在项目的其他地方需要一种脚本语言。

另一种选择，如果有很多数据，请使用sqlite3，因为他们有权声明

小。
快。
可靠。

选择任意三个。

我想补充的：

备份很简单。（只需复制 db 文件。）
更容易切换到另一个数据库、ODBC 等。（比它来自 fugly 文件）

但同样，这是一个更大的问题。对此的“大”答案可能涉及某种特征矩阵或情况列表，例如：

数据量大，或运行时间短

对于大量数据，您可能需要高效的存储，例如数据库。
对于短期运行（通常），您可能需要一些不需要进行大量解析的东西，考虑可以直接使用 mmap:ed 的东西。

配置与什么有关？

主机：
- 我喜欢 /etc 中的 YAML。这是在 Windows 中重新实现的吗？
用户：
- 您是否允许用户使用文本编辑器编辑配置？
- 是否应该集中管理？注册表/gconf/远程数据库？
- 用户可能有几个不同的个人资料？
项目：
- 项目目录中的文件？（版本控制通常遵循这种模式……）

复杂性

只有几个平面值吗？考虑 YAML。
数据是嵌套的，还是以某种方式依赖的？（这就是有趣的地方。）
允许某种形式的脚本编写可能是一个理想的功能吗？
模板可以看作是一种配置文件..

【讨论】：

【解决方案7】：

XML、JSON、INI。
他们都有自己的长处和短处。
在应用程序上下文中，我觉得抽象层很重要。
如果您可以选择一种在人类可读性和您希望如何访问/抽象代码中的数据之间取得良好中间立场的数据结构方式，那么您就是黄金。

我们主要在我工作的地方使用 XML，我真的不敢相信配置文件在第一次读取或写入后作为对象加载到缓存中，然后从程序的其余部分抽象出来，真的是对 CPU 和磁盘空间都没有太大影响。
而且它的可读性也很好，只要你正确地构建文件。

所有平台上的所有语言都通过一些非常常见的库支持 XML。

【讨论】：

【解决方案8】：

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

【讨论】：

Kuro5hin 引用 line 和 char 计数作为使用 YAML 而不是 XML 的原因。我想知道他为什么忘记引用“支持工具和库的数量”？ YAML：2，XML：2,000,000。
Yaml 的库比 2 个多得多。yaml.org
我喜欢 YAML，yaml.org 上列出了大约 12 种带有第三方库的语言。但是默认情况下唯一支持 YAML 的语言似乎是 Ruby（从 1.9.2 开始）。还有其他人吗？添加依赖项可能很麻烦。
我不确定这是否是 @cheeso 的意图，但我认为只有 2 个库可供选择（而不是 2M）作为一个好处而不是一个缺点（特别是如果他们有这两个对...）
@Cheeso 如果我使用的语言有一个编写良好的 YAML 库，那么我使用的语言有 11 个 XML 库并不重要。当然，你的上升到十一点。但是，您最后一次在一个程序中使用两个 XML 库是什么时候？（如果该问题的答案不是“从不”，您可能需要考虑另一项工作。）

【解决方案9】：

@Herms

我真正的意思是坚持软件应该为任何给定平台存储配置值的推荐方式。

你经常得到的也是这些应该/可以修改的推荐方式。就像程序中的配置菜单或“系统首选项”应用程序中的配置面板（用于系统服务软件，即）。不允许最终用户直接通过 RegEdit 或 NotePad 修改它们...

为什么？

最终用户（=客户）习惯于他们的平台
备份系统可以更好地保存“安全设置”等

@nineside

关于“库的选择”，尝试链接（静态链接）任何选定的库，以降低在最终用户机器上陷入版本冲突的风险。

【讨论】：

如果我们能找到一些为各种配置文件格式提供统一 API 的库，这种方式的论据会更有说服力。

【解决方案10】：

回复：epatel 的评论

我认为最初的问题是询问管理员将要执行的应用程序配置，而不仅仅是存储用户偏好。您提供的建议似乎更多地针对用户偏好而不是应用程序配置，并且通常不是用户会直接处理的东西（应用程序应该在 UI 中提供配置选项，然后更新文件）。我真的希望您永远不要让用户必须查看/编辑注册表。 :)

至于实际问题，我想说 XML 可能还可以，因为很多人会习惯于使用它进行配置。只要您以易于使用的方式组织配置值，那么“尖括号税”应该不会太糟糕。

【讨论】：

【解决方案11】：

我们使用的是 ini 风格的配置文件。我们使用Nini 库来管理它们。 Nini 使它非常易于使用。 Nini 最初用于 .NET，但已使用 Mono 移植到其他平台。

【讨论】：

ini 没有被任何标准定义，并且作为键/值存储有一些限制

【解决方案12】：

我们使用属性文件，仅仅是因为 Java 本身就支持它们。几个月前，我看到 SpringSource Application Platform 使用 JSON 来配置他们的服务器，看起来非常有趣。我compared various configuration notations 得出的结论是，XML 似乎是目前最合适的。它有很好的工具支持，而且与平台无关。

【讨论】：

【解决方案13】：

在没有开始新的圣战的情况下，“尖括号税”帖子的情绪是我主要不同意杰夫的一个领域。 XML 没有任何问题，它是人类可读的（与 YAML 或 JSON 或 INI 文件一样多），但请记住它的意图是由机器读取。大多数语言/框架组合都带有某种免费的 XML 解析器，这使得 XML 成为一个不错的选择。

此外，如果您使用的是像 Visual Studio 这样的优秀 IDE，并且如果 XML 带有架构，您可以将架构提供给 VS，然后神奇地获得智能感知（例如，您可以为 NHibernate 获得一个）。

最终，您需要考虑在生产环境中多久接触一次这些文件，可能不会那么频繁。

这仍然为我说明了有关 XML 以及为什么它仍然是配置文件的有效选择的全部内容（来自 Tim Bray）：

“如果您想提供通用数据，接收者可能会想用这些数据做一些无法预料的奇怪和疯狂的事情，或者如果您想对 i18n 非常偏执和挑剔，或者如果您发送的内容更像是一个文档而不是一个结构，或者数据的顺序是否重要，或者数据是否可能长期存在（例如，超过几秒钟）XML 是要走的路。在我看来，XML 和 XPath 的组合对于需要可扩展的数据格式来说是一个最佳选择。也就是说，很容易编写 XML 处理代码，在消息格式发生更改时不会失败，而这些更改不会触及您关心的部分。”

【讨论】：

希望我能多点赞

【解决方案14】：

据我所知，如果您使用 .NET，Windows 注册表不再是存储配置的首选方式 - 现在大多数应用程序都使用 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】：

您在哪个平台上工作？我建议尝试使用首选/常用方法。

MacOSX - plists
Win32 - 注册表（或者这里有一个新的，我在上面开发很久了）
Linux/Unix - ~/.apprc（可能是名称-值）

【讨论】：

问题现在指定“跨平台”。