我正在评估Zend_Config_Ini与使用简单常量文件的好处。
e.g。 -
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是一种技术，从长远来看，随着应用的增长，这种技术会更好吗？
答案 0 :(得分：4)
将Registry与配置一起使用的主要优点是避免污染全局命名空间。比如说，你想要包含第三方lib，你的app和lib都定义了一个常量DB_HOST。不好。
此外，Zend Framework中的许多工厂都使用config对象来创建实例。 Zend_Db就是一个很好的例子。您只需传递它$this->database，它将需要实例化您的适配器。
您还可以使用自定义功能扩展注册表，例如查找方法或类似的东西。查看福勒的pattern description。
答案 1 :(得分：1)
Zend_Config的一个很好的优点是你不依赖于“PHP源代码文件”;只需一个.ini文件 - 有些人更喜欢修改.ini文件而不是PHP文件。
以编程方式修改.ini / XML文件更容易 - 有类/函数可以做到这一点！
使用.ini文件和Zend_Config，您还可以提供良好的功能;例如，部分之间的继承（即，你可以有一个“通用”部分，以及覆盖某些值的“staging”和“production”）
关于Zend_Config也可能有点兴趣的事情就是同情：Zend Framework与Zend_Application已经假设你将拥有一个配置文件;那么，为什么不是第二个呢？或者甚至重复使用第一个？
与几个类的Framework相同，它可以使用Zend_Config的实例工作或配置;如果你已经拥有那个，它会突然变得容易; - ）
如果我必须在带有define的PHP文件和.ini文件之间做出选择，对于可配置的东西，我可能会在需要时使用.ini文件（和Zend_Config + Zend_Registry ）
答案 2 :(得分：1)
是的，你是对的，使用Zend认可的配置方法比定义一系列全局常量更复杂。你获得的好处是
如果您需要将应用程序与其他项目集成，则使用全局常量表示应用程序配置可能会导致问题。另一个项目有一个名为DB_HOST的常量的可能性是多少？使用混合系统的开发人员如何知道哪些常量是应用程序与集成应用程序的配置？
因此，您有一个包含所有配置值的文件。你打算如何将它部署到不同的环境中？ （生产，升级等）你很可能是一个能够提出解决方案的聪明人，但是另一个开发人员如何进入你的项目会知道该解决方案是如何工作的？您的应用程序中的其他模块如何知道如何读取全局配置？
Zend_Config已经“解决”了许多问题。通过预先考虑更多的复杂性和抽象，您可以获得一条已知的前进路径，并且可以花更多的时间来解决应用程序的问题，而不是发明和支持Yet Another Configuration System。