我看到的具有相对优点/缺点的选项是:
基于文件的机制
这些要求您的代码在特定位置查找以查找ini文件。这是一个很难解决的问题,并且总是在大型PHP应用程序中出现。但是,您可能需要解决问题才能找到在运行时合并/重新使用的PHP代码。
常用的方法是始终使用相对目录,或者从当前目录向上搜索以找到在应用程序的基本目录中唯一命名的文件。
用于配置文件的常见文件格式是PHP代码,ini格式的文件,JSON,XML,YAML和序列化的PHP
PHP代码
这为表示不同的数据结构提供了极大的灵活性,并且(假定通过包含或要求处理了它)解析后的代码将可从操作码缓存中获得,从而带来性能优势。
所述的include_path提供用于提取的文件的潜在位置,而不依赖于额外的代码的装置。
另一方面,将配置与代码分开的主要原因之一是要分开职责。它提供了将更多代码注入运行时的途径。
如果配置是通过工具创建的,则可以验证工具中的数据,但是没有标准函数可以像HTML,URL,MySQL语句,shell命令那样,将要嵌入PHP代码的数据转义。 。
序列化数据
对于少量配置(最多约200项),这是相对有效的,并允许使用任何PHP数据结构。它只需要很少的代码就可以创建/解析数据文件(因此,您可以花更多的精力来确保仅使用适当的权限来编写该文件)。
写入文件的内容转义会自动处理。
由于可以序列化对象,因此确实可以通过读取配置文件(__wakeup magic方法)来调用代码。
结构化文件
按照Marcel或JSON或XML的建议将其存储为INI文件,还提供了一个简单的api,可以将文件映射到PHP数据结构(除XML外,可以转义数据并创建文件),同时消除代码调用使用序列化PHP数据的漏洞。
它具有与序列化数据类似的性能特征。
数据库存储
最好考虑在您具有大量配置但对当前任务所需的内容有选择性的情况下-我很惊讶地发现,在大约150个数据项下,从本地MySQL实例检索数据比从数据库中检索数据更快。反序列化数据文件。
OTOH不是存储用于连接数据库的凭据的好地方!
执行环境
您可以在运行PHP 的执行环境中设置值。
这消除了PHP代码在特定位置查找配置的任何要求。OTOH不能很好地扩展到大量数据,并且很难在运行时进行通用更改。
在客户端上
我没有提到的用于存储配置数据的一个地方是客户端。同样,网络开销意味着无法很好地扩展到大量配置。并且由于最终用户可以控制数据,因此必须以可以检测到任何篡改的格式(即,使用密码签名)存储数据,并且不应包含因其泄露而受到损害的任何信息(即,可逆加密)。
相反,这对于存储最终用户拥有的敏感信息有很多好处-如果您不将其存储在服务器上,则无法从那里窃取它。
网络目录
存储配置信息的另一个有趣的地方是DNS / LDAP。这将适用于少量的小信息-但您无需遵循第一标准格式-例如SPF。
基础架构支持缓存,复制和分发。因此,它非常适合大型基础架构。
版本控制系统
像代码这样的配置应该进行管理和版本控制-因此,直接从VC系统获取配置是可行的解决方案。但是通常这会带来很大的性能开销,因此建议使用缓存。