在工作中我们使用.ini文件在调用框架的其余部分之前设置变量(我认为它是
function getConfigVars(){
//read my_config.ini file
....
//call framework
}
我一直想知道这样做是否有好处。
在我看来,你必须编写访问规则来阻止人们从网上查看它,php必须解析它并理解它。
那么,为什么要使用my_config.ini而不是my_config.php?它不像任何人应该在设置后触摸它,只是调用变量似乎更方便,并且能够让IDE自动完成文本,无论你在哪里使用ini变量/解析错误。
答案 0 :(得分:13)
对于那些提出这个问题的人,因为他们想知道在使用必须解析的INI文件和简单包含的PHP文件(并且可以通过PHP缓存)之间是否存在任何性能差异:是的,那里是差异,但它们是如此之小,以至于它并不重要。
我的基准测试场景是一个config.ini
文件,其中包含20个键/值对和一个config.php
文件,其中包含与定义相同的20个键/值对。在Ubuntu Linux 13.04上PHP版本是5.4.9。
key1 = value1
...
key20 = value20
VS
<?php
define("key1", "value1");
...
define("key2", "value20");
两个测试脚本,包括配置:
<?php
$CONF = parse_ini_file("config.ini");
VS
<?php
require_once "config.php";
我使用ab -c 25 -n 10000
测试了效果。
没有PHP缓存的结果:
ini: Requests per second: 2660.89 [#/sec] (mean)
php: Requests per second: 2642.28 [#/sec] (mean)
APC PHP缓存的结果:
ini: Requests per second: 3294.47 [#/sec] (mean)
php: Requests per second: 3307.89 [#/sec] (mean)
我多次运行测试,自然数字每次都会变化,但共识是:config.ini
在没有使用PHP缓存时稍快一点,config.php
稍快一点使用PHP缓存。但差异很小,决定不应以绩效为基础。
答案 1 :(得分:10)
你的问题提出了一个公平的观点,当然。
赞成.ini
个文件的几点:
使用其他语言的文件。如果您曾经想要使用Perl,Python,Ruby等脚本执行一些特别容易使用该语言并且需要访问项目设置的内容,那么如果您将设置存储在PHP文件中,则会运气不佳。
人工编辑数据。虽然你在你的问题中解雇了它,但意图是否有可能最终有人可能会在那里戳,而且可能不是技术人员。 INI格式比PHP代码更不可怕,即使它只是一堆变量声明
更新设置。我认为创建一个新的INI文件比编写PHP文件要容易得多。然而,这是非常主观的,但值得一提。
设置变量之间的关系。使用INI文件为您的设置提供层次结构非常容易/直观。虽然使用PHP也可以实现这一点,但如果您尝试使用深层嵌套的关联数组来存储信息,那么它就不那么简单了。如果你想要深层嵌套的关联数组来存储信息,那就不好看了。
除此之外,在大多数情况下,对INI“必须保护它免受Web访问”的冲击并不重要,因为大多数PHP项目(至少是我所属的那些项目)都拥有相当数量的代码从根文件夹,设置通常去那里。
答案 2 :(得分:10)
Zend Framework包含一个配置解析,用于解析以ini格式(Zend_Config_Ini)编写的文件,听起来这就是你正在使用的。
配置文件不应该位于文档根目录中,如果它不在您的文档根目录中,则不需要重写规则,因为无论如何都没有人可以访问它。
INI格式专门用于提供配置数据键层次结构和配置数据段之间的继承。通过用点或句点字符(。)分隔键来支持配置数据层次结构。部分可以通过使用冒号字符(:)跟随部分名称以及要从中继承数据的部分的名称来扩展或继承其他部分。
来自Zend_Config_Ini页。
Zend Framework使用它来允许您拥有多个配置参数,一个用于分段,一个用于开发,一个用于生产。这也允许轻松设置生产和开发的数据库设置,并具有两个非常不同的设置。在ini文件中设置的不同路径位于包含的位置。这使得将代码从开发转移到生产变得更加容易,因为知道开发的所有内容都将立即关闭。
当然,这可以通过PHP脚本实现,但是需要更多地解析各种配置变量以及if / then检查,而使用parse_ini_file()会自动为您完成所有这些。
其他答案也已经指出,非程序员可能需要更改设置为配置变量的网站上的变量和/或某些内容(例如,站点布局中使用的站点标题)。 INI文件易于理解和阅读,即使对于之前从未编程的人也是如此。
我目前正在处理的网站示例:
[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"
resources.view[] =
[staging : production]
[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db
这使得为代码可以运行的各种环境提供多个数据集非常容易。
答案 3 :(得分:1)
非程序员修改配置变量可能更容易......如果您的工作场所需要这样做。
我发现<?php
和?>
的谨慎放置可以阻止它显示,而parse_ini_file()仍会从文件中获取相关数据。
保护它的最佳方法是将其置于docroot之上,并拒绝在服务器设置中访问* .ini。