PHP Zend框架 - Zend_Config和全局状态

Question

我正在评估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是一种技术，从长远来看，随着应用程序的增长更好？

Answer 1

将Registry与配置一起使用的主要优点是避免污染全局命名空间。 比如说，你想要包含第三方lib，你的app和lib都定义了一个常量DB_HOST。 不好。

此外，Zend Framework中的许多工厂都使用config对象来创建实例。 Zend_Db就是一个很好的例子。 你只需传递$this->database ，它将需要实例化你的适配器。

您还可以使用自定义功能扩展注册表，例如查找器方法或类似的东西。 检查Fowler的模式描述 。

Answer 2

Zend_Config一个很好的优点是你不依赖于“PHP源代码文件”; 只需一个.ini文件 - 有些人更喜欢修改.ini文件而不是PHP文件。

并且以编程方式修改.ini / XML文件更容易 - 有类/函数可以做到这一点！

使用.ini文件和Zend_Config ，您还可以提供良好的功能; 例如，部分之间的继承（即，您可以拥有“通用”部分，以及覆盖某些值的“暂存”和“生产”）

关于Zend_Config也可能有点兴趣的事情就是使用：Zend Framework， Zend_Application ，已经假设你将拥有一个配置文件; 那么，为什么不是第二个呢？ 甚至重复使用第一个？

并且它与Framework的几个类相同，它可以使用Zend_Config的实例工作或配置; 如果你已经拥有那个，它会突然变得容易;-)

如果我必须在带有define和.ini文件的PHP文件之间进行选择，对于可配置的东西，我可能会使用.ini文件（需要时使用Zend_Config + Zend_Registry ） 。

Answer 3

是的，你是对的，使用Zend认可的配置方法比定义一系列全局常量更复杂。 你获得的好处是

没有全局命名空间冲突

如果您需要将应用程序与其他项目集成，则使用全局常量表示应用程序配置可能会导致问题。 另一个项目有一个名为DB_HOST的常量的可能性有DB_HOST ？ 使用混合系统的开发人员如何知道哪些常量是应用程序与集成应用程序的配置？

以他人的工作为基础

因此，您有一个包含所有配置值的文件。 你打算如何将它部署到不同的环境中？ （生产，升级等）你很可能是一个能够提出解决方案的聪明人，但是另一个开发人员如何进入你的项目会知道该解决方案是如何工作的？ 您的应用程序中的其他模块如何知道如何读取全局配置？

Zend_Config已经“解决”了许多问题。 通过预先考虑更多的复杂性和抽象，您可以获得前进的已知路径，并且可以花更多的时间来解决应用程序的问题，而不是发明和支持Yet Another Configuration System。