好的,所以我不想在这里开始一场神圣的战争,但我们正在努力巩固我们处理应用程序配置文件的方式,我们正在努力做出最好的方法来决定.目前,我们分发的每个应用程序都使用它自己的ad-hoc配置文件,无论是属性文件(ini样式),XML还是JSON(目前仅在内部使用!).
我们大部分的代码是Java的时刻,所以我们一直在寻找的Apache共享配置,但我们发现它是非常详细.我们也看过XMLBeans,但看起来好像很多.我也觉得好像我被推向XML的格式,但我的客户和同事都感到忧虑尝试别的东西.我可以从客户的角度去理解它,每个人都听到了XML的,但在一天结束的时候,不应该使用的是合适的工具?
现在人们在生产系统中使用哪些格式和库,是否有其他人试图避免使用尖括号税?
编辑:真正需要成为一个跨平台的解决方案:Linux,Windows,Solaris等,用于与配置文件接口的库的选择与格式的选择同样重要.
YAML,原因很简单,它与XML相比,它提供了非常易读的配置文件.
XML:
Bob Abooey adv 555-1212 | ahunter@example1.com babooey@example2.com
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,因为
我可以允许宽度=高度*(1 + 1/3)之类的东西
我可以提供自定义功能
我可以禁止任何其他事情.(例如,Python(包括泡菜)不可能)
无论如何,我可能还想在项目的其他地方使用脚本语言.
另一个选择,如果有很多数据是使用sqlite3,因为他们是正确的索赔
小.
快速.
可靠.
选择任意三个.
我想补充一下:
备份非常简单.(只需复制db文件.)
更容易切换到另一个数据库,ODBC,等等.(比它来自fugly文件)
但同样,这是一个更大的问题.对此的"大"答案可能涉及某种特征矩阵或情况列表,例如:
对于大量数据,您可能需要高效的存储,例如数据库.
对于短期运行(通常),您可能需要一些您不需要进行大量解析的东西,可以考虑直接使用mmap:ed.
主办:
我喜欢/ etc中的YAML.这是在Windows中重新实现的吗?
用户:
您是否允许用户使用文本编辑器编辑配置?
它应该是集中管理的吗?Registry/gconf/remote db?
用户可能有几个不同的配置文件?
项目:
项目目录中的文件?(版本控制通常遵循此模型......)
是否只有几个平面值?考虑YAML.
数据是嵌套的,还是以某种方式依赖?(这是有趣的地方.)
允许某种形式的脚本可能是一个理想的功能吗?
模板可以被视为一种配置文件..
XML XML XML XML.我们在这里讨论配置文件.如果你没有在性能密集的情况下序列化对象,则没有"尖括号税".
除了机器可读之外,配置文件必须是人类可读的并且是人类可理解的.XML是两者之间的良好折衷.
如果你的店里有人害怕那种新奇的XML技术,我觉得你很难受.
没有开始新的圣战,"尖括号税"的情绪是我主要不同意杰夫的一个领域.XML没有任何问题,它具有合理的人类可读性(与YAML或JSON或INI文件一样多),但请记住它的意图是由机器读取.大多数语言/框架组合都带有一种免费的XML解析器,这使得XML成为一个很好的选择.
此外,如果您使用的是像Visual Studio这样的好IDE,并且如果XML附带了模式,您可以将模式提供给VS,并且神奇地获得智能感知(例如,您可以为NHibernate获取一个模式).
毫无疑问,你需要考虑一下你在生产中接触这些文件的频率,可能不常见.
这仍然说明了XML和它为什么仍然是配置文件的有效选择(来自Tim Bray):
"如果你想提供接收器可能想做的通用数据无法预料的奇怪和疯狂的事情,或者如果你想真正偏执和挑剔i18n,或者你发送的内容更像是一个文件而不是一个结构,或者如果数据的顺序很重要,或者如果数据可能是长寿的(比如,超过几秒),那么XML就是可行的方法.在我看来,XML和XPath的组合也会出现问题.需要可扩展的数据格式的最佳位置;也就是说,编写XML处理代码非常容易,如果消息格式的更改不会触及您关注的部分,则不会失败. "
@Guy
但应用程序配置并不总是键/值对.查看tomcat配置,了解它侦听的端口.这是一个例子:
您可以拥有任意数量的连接器.在文件中定义更多,并且存在更多连接器.不再定义,不再存在.使用普通的旧键/值对没有好办法(imho).
如果您的应用程序的配置很简单,那么简单的东西就像读入字典的INI文件一样可能很好.但对于像服务器配置这样更复杂的东西,INI文件将是一个巨大的难以维护,而更像XML或YAML的结构会更好.这一切都取决于问题集.