应用配置文件

时间：2008-08-15 11:19:51

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

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

目前我们的大多数代码都是Java，所以我们一直在关注Apache Commons Config，但我们发现它非常详细。我们也看了XMLBeans，但看起来好像很多。我也觉得好像我被推向XML作为一种格式，但我的客户和同事都对尝试别的东西感到担忧。我可以从客户的角度理解它，每个人都听说过XML，但最终，不应该使用正确的工具来完成工作吗？

现在人们在生产系统中使用哪些格式和库，是否有其他人试图避免使用angle bracket tax？

编辑： 确实需要成为跨平台的解决方案：Linux，Windows，Solaris等以及用于与配置文件交互的库的选择是与格式的选择一样重要。

15 个答案:

答案 0 :(得分：28)

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

答案 1 :(得分：14)

首先：这是一个非常大的辩论问题，而不是快速的Q + A.

我现在最喜欢的是简单地加入Lua，因为

  • 我可以允许宽度=高度*（1 + 1/3）
    • 之类的东西
  • 我可以自定义功能
  • 我可以禁止任何其他事情。 （例如，Python（包括泡菜）不可能。）
  • 无论如何，我可能还想在项目的其他地方使用脚本语言。

另一种选择，如果有大量数据是使用sqlite3，因为他们是正确的

  • 小。
  • 快速。
  • 可靠。

选择任意三个。

我想补充一下：

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

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

数据量或短运行时间

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

配置与什么相关？

  • 主机：
    • 我喜欢/ etc中的YAML。这是在Windows中重新实现的吗？
  • 用户：
    • 您是否允许用户使用文本编辑器编辑配置？
    • 它应该是集中管理的吗？ Registry / gconf / remote db？
    • 用户可以使用多个不同的个人资料吗？
  • 项目：
    • 项目目录中的文件？ （版本控制通常遵循此模型......）

复杂性

  • 是否只有几个平面值？考虑YAML。
  • 数据是嵌套的，还是以某种方式依赖？ （这是它变得有趣的地方。）
  • 允许某种形式的脚本可能是一个理想的功能吗？
  • 可以将模板视为一种配置文件..

答案 2 :(得分：10)

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

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

如果你的商店有人害怕那种新奇的XML技术，我觉得你很难受。

答案 3 :(得分：9)

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

另外，如果您使用的是像Visual Studio这样的好IDE，并且如果XML附带了模式，您可以将模式提供给VS，并且神奇地获得智能感知（例如，您可以为NHibernate获取一个）。 / p>

你需要考虑一下你在生产过程中经常触摸这些文件的频率，可能不常见。

对于我来说，这仍然说明了XML及其为什么仍然是配置文件的有效选择（来自Tim Bray）：

“如果你想提供接收者可能想做的通用数据无法预料的奇怪和疯狂的事情，或者如果你想真的偏执和挑剔i18n，或者你发送的是什么更像是一个文档而不是一个结构，或者如果数据的顺序很重要，或者如果数据可能是长寿的（比如，超过几秒），那么XML就是最佳选择。 在我看来，XML和XPath的结合为需要可扩展的数据格式提供了一个最佳点;也就是说，编写XML处理代码非常容易，如果消息格式发生变化而不会触及您关注的部分，则不会失败。“

答案 4 :(得分：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的结构会更好。这一切都取决于问题集。

答案 5 :(得分：2)

我们正在使用ini样式配置文件。我们使用Nini库来管理它们。 Nini使它非常易于使用。 Nini非常适合.NET，但已经使用Mono移植到其他平台。

答案 6 :(得分：2)

XML，JSON，INI。
他们都有自己的长处和短处 在应用程序上下文中，我觉得抽象层是重要的东西 如果您可以选择一种方法来构建数据，这是人类可读性与您希望如何在代码中访问/抽象数据之间的良好中间点，那么您就是金色的。

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

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

答案 7 :(得分：1)

@Herms

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

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

为什么？

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

    3. @ninesided

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

答案 8 :(得分：1)

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

如果您的数据有点复杂，使用嵌套等，您可能最好使用YAML，XML或SQLite。

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

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

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

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

答案 9 :(得分：0)

据我所知，如果您使用.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

答案 10 :(得分：0)

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

答案 11 :(得分：0)

回复：epatel的评论

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

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

答案 12 :(得分：0)

这里可能有点切线，但我的意见是，当应用程序首次启动时，应该将配置文件读入键值字典/哈希表，并始终通过此对象访问以获得速度。通常，键/值表以字符串形式开始，但对象中的辅助函数执行DateTime GetConfigDate（字符串键）等操作...

答案 13 :(得分：0)

我认为唯一重要的是选择您喜欢的格式并快速导航。 XML和JSON都是配置的优良格式，并得到广泛支持 - 技术实现并不是问题的关键所在。这是100％关于什么使配置文件的任务更容易。

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

答案 14 :(得分：-3)

你在做什么平台？我建议尝试使用首选/常用方法。

  1. MacOSX - plists
  2. Win32 - 注册表（或者我在这里开发了一个新的注册表）
  3. Linux / Unix - 〜/ .apprc（也许是名字值）
相关问题
最新问题