应用程序配置文件[关闭]
-
08-06-2019 - |
题
好的,所以我不想在这里开始一场圣战,但我们正在尝试巩固我们处理应用程序配置文件的方式,并且我们正在努力决定采取的最佳方法。目前,我们分发的每个应用程序都使用自己的临时配置文件,无论是属性文件(ini 样式)、XML 还是 JSON(目前仅供内部使用!)。
目前我们的大部分代码都是 Java,所以我们一直在研究 Apache 公共配置, ,但我们发现它相当冗长。我们也看过 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
第一的:这是一个非常大的辩论问题,而不是一个快速的问答。
我现在最喜欢的是简单地包括 卢阿, , 因为
- 我可以允许宽度=高度*(1+1/3)之类的东西
- 我可以提供自定义功能
- 我可以禁止任何其他事情。(例如,在 Python(包括 pickles)中是不可能的。)
- 无论如何,我可能会在项目的其他地方想要一种脚本语言。
如果有大量数据,另一种选择是使用 sqlite3, ,因为他们的主张是正确的
- 小的。
- 快速地。
- 可靠的。
选择任意三个。
我想补充一点:
- 备份非常简单。(只需复制 db 文件即可。)
- 更容易切换到另一个数据库,ODBC,等等。(比它来自fugly-file)
但这又是一个更大的问题。对此的“大”答案可能涉及某种特征矩阵或情况列表,例如:
数据量大或运行时间短
- 对于大量数据,您可能需要高效的存储,例如数据库。
- 对于短期运行(通常),您可能想要一些不需要进行大量解析的东西,请考虑可以直接进行 mmap:ed 的东西。
配置有什么关系?
- 主持人:
- 我喜欢 /etc 中的 YAML。Windows 中重新实现了吗?
- 用户:
- 您是否允许用户使用文本编辑器编辑配置?
- 它应该集中管理吗?注册表/gconf/远程数据库?
- 可能用户有几种不同的 简介?
- 项目:
- 项目目录中的文件?(版本控制通常遵循这种模型......)
复杂
- 只有几个固定值吗?考虑 YAML。
- 数据是嵌套的还是以某种方式依赖?(这就是有趣的地方。)
- 允许某种形式的脚本编写可能是一个理想的功能吗?
- 模板可以被视为一种配置文件。
在不开始一场新的圣战的情况下,“尖括号税”帖子的情绪是我所关注的一个领域 主要不同意 和杰夫。XML 没有任何问题,它是人类可读的(与 YAML 或 JSON 或 INI 文件一样),但请记住它的目的是由机器读取。大多数语言/框架组合都免费附带某种 XML 解析器,这使得 XML 成为一个不错的选择。
另外,如果您使用的是 Visual Studio 等优秀的 IDE,并且 XML 带有架构,您可以将该架构提供给 VS,然后您就会神奇地获得智能感知(例如,您可以为 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 最初适用于 .NET,但已使用 Mono 移植到其他平台。
XML、JSON、INI。
他们都有自己的优点和缺点。
在应用程序上下文中,我觉得抽象层很重要。
如果您可以选择一种在人类可读性和您希望如何在代码中访问/抽象数据之间建立良好中间立场的数据结构方法,那么您就是黄金。
我们在工作中主要使用 XML,我真的不敢相信配置文件在第一次读取或写入后作为对象加载到缓存中,然后从程序的其余部分中抽象出来,真的是这样吗?对 CPU 和磁盘空间都没有影响。
只要你正确构建文件,它也非常可读。
所有平台上的所有语言都通过一些非常常见的库支持 XML。
@爱马仕
我真正的意思是坚持软件应为任何给定平台存储配置值的推荐方式。
然后您经常得到的也是应该/可以修改这些建议的方法。就像程序中的配置菜单或“系统首选项”应用程序中的配置面板(对于系统服务软件,即)。不允许最终用户直接通过 RegEdit 或 NotePad 修改它们......
为什么?
- 最终用户(=客户)习惯了他们的平台
- 备份系统可以更好地保存“安全设置”等
@九边
关于 ” 图书馆的选择 ”,尝试链接(静态链接)任何选定的库,以降低最终用户计算机上陷入版本冲突战争的风险。
如果您的配置文件是一次写入、启动时只读,并且您的数据是一堆名称值对,那么您的最佳选择是开发人员可以首先开始工作的配置文件。
如果您的数据有点复杂,有嵌套等,那么使用 YAML、XML 或 SQLite 可能会更好。
如果您需要嵌套数据和/或在启动后查询配置数据的能力,请使用 XML 或 SQLite。两者都有非常好的结构化/嵌套数据查询语言(XPATH 和 SQL)。
如果您的配置数据高度标准化(例如第五范式)你最好使用 SQLite,因为 SQL 更适合处理高度规范化的数据。
如果您计划在程序运行期间写入配置数据集,那么您最好使用 SQLite。例如,如果您正在从另一台计算机下载配置数据,或者您正在根据先前程序执行中收集的数据做出未来的程序执行决策。SQLite 实现了一个非常强大的数据存储引擎,当您遇到断电或程序由于错误而处于不一致状态时,该引擎极难损坏。损坏的数据会导致高昂的现场支持成本,而 SQLite 将比任何本土解决方案甚至流行的 XML 或 YAML 库做得更好。
查看我的页面 有关 SQLite 的更多信息。
据我所知,如果您使用 .NET,Windows 注册表不再是存储配置的首选方式 - 大多数应用程序现在都使用 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 似乎是目前最合适的。它有很好的工具支持并且相当独立于平台。
关于:埃帕特尔的评论
我认为最初的问题是询问管理员将要做的应用程序配置,而不仅仅是存储用户首选项。您提供的建议似乎更多地针对用户首选项,而不是应用程序配置,并且通常不是用户直接处理的内容(应用程序应在 UI 中提供配置选项,然后更新文件)。我真的希望你永远不会让用户必须查看/编辑注册表。:)
至于实际问题,我认为 XML 可能没问题,因为很多人会习惯使用它进行配置。只要您以易于使用的方式组织配置值,那么“尖括号税”应该不会太糟糕。
也许这里有点离题,但我的观点是,当应用程序首次启动时,应该将配置文件读入键值字典/哈希表,并从那时起始终通过该对象进行访问以提高速度。通常,键/值表以字符串到字符串的形式开始,但对象中的辅助函数会执行诸如 DateTime GetConfigDate(string key) 等操作。
我认为唯一重要的是选择您喜欢且可以快速导航的格式。XML 和 JSON 都是很好的配置格式,并且得到了广泛的支持——我认为技术实现并不是问题的关键。它 100% 是关于如何让您更轻松地完成配置文件的任务。
我已经开始使用 JSON,因为我经常使用它作为数据传输格式,并且序列化器可以轻松加载到任何开发框架中。我发现 JSON 比 XML 更容易阅读,这使得处理多个服务(每个服务都使用一个经常修改的配置文件)对我来说更容易!
您在什么平台上工作?我建议尝试使用首选/常用方法。
- MacOSX - plists
- Win32 - 注册表(或者这里有一个新的注册表,自从我在它上开发以来很久)
- Linux/Unix - ~/.apprc (也许是名称-值)