在PHP中管理全局范围的数据和设置的推荐方法是什么？

在PHP中，可以使用不同的方式存储设置。我更喜欢使用PHP数组或INI文件。

一旦你有了这个设置，就可以编写一个全局可用的访问器类。如果你愿意，可以将其设为单例模式，但并不是必需的。

这个类将解析你的设置存储，并创建一个内部数据结构。只需确保其中没有任何设置器，以防止数据被覆盖。可以参考Zend是如何实现其Zend_Config类的。这是我要说的：http://framework.zend.com/manual/en/zend.config.html

确保你的访问器类在全局范围内可用，这样你就可以随时获取设置。

推荐在PHP中管理全局作用域数据和设置的方法是使用Zend_Config。Zend_Config提供了多种常用的配置实现方式，包括数组、ini文件、xml文件、json文件和yaml文件。其中数组是最直接和简单的解决方案，但分散且难以阅读。而其他格式具有更明显的优势，比如ini文件可以提供层次结构和继承功能，xml文件非常灵活，json文件易于阅读且可以直接通过js访问，yaml文件则可以直接写入序列化数组。

使用常量并不是一个好主意，因为应用程序并不总是需要查看所有的配置选项，而且更重要的是，常量不能嵌套，而嵌套在配置中是非常重要的。

Zend_Config_Ini可能看起来有点多余，它只是一个笨重的封装器，包装了parse_ini_file和array_merge。而且如果它能够用于更新配置文件（在SO上更常见的话题），它可能会删除用户的注释。

还有Zend_Config_Writer，其中包括Zend_Config_Writer_Ini！这个封装器并不臃肿，因为它还提供了section功能。

我预料到了，它会删除.ini文件的注释。至于[section]功能，parse_ini_file已经支持了。我仍然不明白优势在哪里。

优势在于，你可以随时更换适配器，而不需要更改代码。这就是框架的作用，它们封装各种接口以实现统一。如果只有ini文件，并且确信永远只使用ini文件，我会同意你的观点，可以使用parse_ini_file和array_merge来完成。

在PHP中管理全局作用域数据和设置的推荐方法是使用INI文件。通过创建一个名为configuration.ini的文件，将所有系统配置（例如数据库信息、URL等）存储在其中。在读取时，只需使用PHP的默认函数解析这个INI文件即可。如果解析一个INI文件，为什么不直接包含一个常量文件呢？这显然更快，并且完全达到了同样的效果。

如今，所有的客户都希望能够在他们的端上更改配置。所以如果我们始终使用PHP变量作为文件，那会让客户感到困惑。所以INI文件是让那些对PHP不熟悉的人更简单的唯一方式。

抱歉说这个，但是这是一个可怕的想法。如果你可以构建一个数组或定义常量并将它们包含在项目中，那么没有任何理由使用INI文件然后解析它们。你只是在过程中添加了一个不必要的解析步骤。

使用常量似乎是一个不错的主意，但只是乍一看是这样。如果你考虑一下这在范围方面意味着什么，你会意识到这是一个非常糟糕的主意。你会使配置选项直接从软件的任何地方都可以访问，这肯定会造成维护的噩梦。没有什么好的理由让整个应用程序都知道所有的配置选项，你需要隐藏配置，然后只通过专用处理程序（比如配置类）提供对它的访问，如果只在需要的时候才提供。

如果你使用常量，为什么会产生维护上的错误？从创建一个为应用程序提供值的类和在任何地方都能访问的常量之间有什么不同？我会说，应用程序没有理由不知道它的所有配置选项。当你仔细考虑时，应用程序必须知道它的配置选项。

为什么在不需要的情况下添加解析步骤？

如果你们想用常量来混乱你们的整个应用程序，那就去吧。但是如果你决定要改变存储配置选项的方式，你就必须去到每个地方改变一切，而我只需要将我的解析器类更换为另一个适配器！关键词是封装、单一控制点、分层等。

常量不适合用于配置的另一个原因是它们不支持嵌套！嵌套对于配置来说非常重要。

+1 这个答案没有问题。唯一可以改进的地方是将所有这些包装在一个类中。使用常量和define()的一个问题是数组并不真正支持。而INI文件则支持嵌套，更重要的是级联。所以你可以使用一个INI文件来处理所有的环境，而不是使用基于常量的方法。