我正在评估 Zend_Config_Ini 与使用简单常量文件的优势。
例如-
define('DB_HOST',localhost);
//versus
$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host; // prints "dev.example.com"
唯一的问题是 $config 不可全局访问。那么你需要使用 Zend_Registry 来存储应用程序使用，而不必每次都启动。
这似乎增加了比需要更多的复杂性......我是否遗漏了什么或者 Zend_Config + Zend_Registry 是一种从长远来看随着应用程序增长而更好的技术？
【问题讨论】：
标签： php zend-framework constants config
将注册表与配置一起使用的主要优点是避免污染全局命名空间。假设您想包含第三方库，并且您的应用程序和库都定义了一个常量 DB_HOST。不好。
此外，Zend Framework 中的许多工厂都使用配置对象来创建实例。 Zend_Db 就是一个很好的例子。您只需将它传递给$this->database，它将获取实例化适配器所需的内容。
您还可以使用自定义功能扩展注册表，例如查找器方法或类似的东西。检查 Fowler 的 pattern description。
【讨论】：
Zend_Config 的一个很好的优势是您不依赖于“PHP 源代码文件”；一个 .ini 文件就可以了——有些人更喜欢修改一个 .ini 文件而不是 PHP 文件。
以编程方式修改 .ini / XML 文件更容易 - 有类/函数可以做到这一点！
使用 .ini 文件和Zend_Config，您还可以提供一些不错的功能；例如，部分之间的继承（即，您可以有一个“通用”部分，以及覆盖某些值的“暂存”和“生产”）
关于Zend_Config 的一件事也很有趣：一致性：Zend 框架和Zend_Application 已经假设您将拥有一个配置文件；那么，为什么不是第二个呢？或者甚至重复使用第一个？
Framework 的几个类也是如此，可以通过Zend_Config 的实例来工作或配置；如果你已经有了那个，它会突然变得更容易;-)
如果我必须在带有定义的 PHP 文件和 .ini 文件之间进行选择，对于可配置的东西，我可能会选择 .ini 文件（需要时Zend_Config + Zend_Registry）.
【讨论】：
是的，你是对的，使用 Zend 认可的方法进行配置比定义一系列全局常量更复杂。你得到的好处是
如果您需要将您的应用程序与另一个项目集成，使用全局常量表示您的应用程序配置可能会导致问题。另一个项目有一个名为DB_HOST 的常量的可能性有多大？使用您的混合系统的开发人员如何分辨哪些常量是您的应用程序与集成应用程序的配置？
因此，您有一个包含所有配置值的文件。您将如何将其部署到不同的环境中？ （生产、登台等）您很可能是一个可以提出解决方案的聪明人，但是进入您的项目的其他开发人员如何知道该解决方案是如何工作的？您应用程序中的其他模块如何知道如何读取您的全局配置？
Zend_Config 已经“解决”了许多问题。通过预先考虑更多的复杂性和抽象，您可以获得一条已知的前进道路，并且可以将更多时间用于解决应用程序的问题，而不是发明和支持另一个配置系统。
【讨论】：