PHP Zend Framework-Zend_Configとグローバル状態

Question

私は、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がアプリの成長に応じて長期的に優れた手法ですか？

Answer 1

構成でレジストリを使用する主な利点は、グローバル名前空間の汚染を回避することです。たとえば、サードパーティのライブラリを含めたい場合、アプリとライブラリの両方で定数DB_HOSTを定義します。ダメです。

さらに、Zend Frameworkのファクトリの多くは、configオブジェクトを使用してインスタンスを作成します。 Zend_Db はこの良い例です。 $ this-＆gt; database を渡すだけで、アダプタのインスタンス化に必要なものが必要になります。

レジストリをカスタム機能で拡張することもできます。 finderメソッドまたはそのようなもの。 Fowlerのパターンの説明を確認してください。

Answer 2

Zend_Config の優れた利点は、「PHPソースコードファイル」に依存しないことです。 ; .iniファイルだけでできます-PHPファイルではなく.iniファイルを変更したい人もいます。

そして、プログラムで.ini / XMLファイルを変更するのが簡単です-それを行うクラス/関数があります！

.iniファイルと Zend_Config を使用すると、素晴らしい機能が既に提供されています。たとえば、セクション間の継承（つまり、一部の値を上書きする「ジェネリック」セクション、および「ステージング」および「プロダクション」を持つことができます）

Zend_Config についても興味深いのは、一貫性です。ZendFrameworkと Zend_Application は、すでに1つの設定ファイルがあると想定しています。だから、なぜ2番目のものではないのですか？または、最初のものを再利用しますか？

そして、フレームワークのいくつかのクラスでも同じです。これらは動作するか、 Zend_Config のインスタンスで設定できます。既に持っている場合、突然簡単になります;-）

定義可能なPHPファイルと.iniファイルのどちらかを選択する必要がある場合、構成可能なものについては、おそらく.iniファイル（And Zend_Config + Zend_Registry 必要な場合）。

Answer 3

はい、あなたは正しいです。設定にZend認定の方法を使用することは、一連のグローバル定数を定義するよりも複雑です。利点は次のとおりです

グローバルネームスペース衝突なし

アプリケーションを別のプロジェクトと統合する必要がある場合、グローバル定数がアプリケーション構成を表すと、問題が発生する可能性があります。別のプロジェクトが DB_HOST という名前の定数を持っている可能性は何ですか？ハイブリッドシステムを使用している開発者は、どの定数がアプリケーションと統合アプリケーションの構成であるかをどのように判断できますか？

他者の仕事の上に構築

つまり、すべての設定値を含む単一のファイルがあります。それを異なる環境にどのように展開しますか？ （プロダクション、ステージングなど）あなたはソリューションを思い付く賢い人かもしれませんが、プロジェクトに参加する別の開発者はどのようにそのソリューションが機能するかを知るでしょうか？アプリケーションの他のモジュールは、グローバル構成の読み取り方法をどのように知るのですか？

Zend_Config は既に「解決済み」です問題の多く。事前にもう少し複雑さと抽象化を行うことにより、既知の道を進むことができ、さらに別の構成システムを発明してサポートするのではなく、アプリケーションの問題を解決するのにより多くの時間を費やすことができます。