3

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

4

3 回答 3

4

将注册表与配置一起使用的主要优点是避免污染全局命名空间。假设您想包含第三方库，并且您的应用程序和库都定义了一个常量 DB_HOST。不好。

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

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

于 2009-11-26T22:46:17.467 回答
1

一个不错的优点Zend_Config是您不依赖“PHP 源代码文件”；只需一个 .ini 文件就可以了——有些人更喜欢修改 .ini 文件而不是 PHP 文件。

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

使用 .ini 文件Zend_Config，您还可以使用已经提供的不错的功能；例如，部分之间的继承（即，您可以有一个“通用”部分，以及覆盖某些值的“暂存”和“生产”）


一个有趣的事情Zend_Config也是一致性：Zend FrameworkZend_Application已经假设您将拥有一个配置文件；那么，为什么不是第二个呢？甚至重新使用第一个？

框架的几个类也是如此，它们可以工作或配置Zend_Config; 如果你已经有了那个，它会突然变得更容易;-)


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

于 2009-11-26T22:44:25.953 回答
1

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

没有全局命名空间冲突

如果您需要将您的应用程序与另一个项目集成，让全局常量代表您的应用程序配置可能会导致问题。另一个项目有一个常量命名的机会是什么DB_HOST？使用您的混合系统的开发人员如何分辨哪些常量是您的应用程序与集成应用程序的配置？

以他人的工作为基础

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

Zend_Config已经“解决”了很多问题。通过预先考虑更多的复杂性和抽象，您可以获得一条已知的前进道路，并且可以将更多时间花在解决应用程序的问题上，而不是发明和支持另一个配置系统。

于 2009-11-26T23:01:38.353 回答