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。