あなたの質問に答えないリスクを冒して、私は通常、あなたの質問のようにフィルターやバリデーターなどの低レベルのクラスを、アプリ構成全体を利用できるようにするという意味でアプリケーション対応にしないでください。
むしろ、必要な app-config の部分を正確に特定し、それらの部分をコンストラクター引数としてフィルター/バリデーターに渡すようにしています。
これには次の 2 つの利点があります。
- 依存関係を明確に識別します
- その後、まったく異なる app-config 構造を持つ可能性のある他のプロジェクトでフィルター/バリデーターを使用できます。
例として、検証を実行するときに、カスタム バリデーターがホワイトリストに登録する電子メール アドレスのリストを知る必要があるとします。このホワイトリストは次のように構成に保存さapplication.ini
れます。
whitelist[] = "good1@example.com"
whitelist[] = "good2@example.com"
この app-config オブジェクトは、Zend_Registry
キーの下の「config」に保存されます。
以下を使用して、バリデーターにその情報にアクセスさせることができます。
$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
// use the whitelist
しかし、これは、IMO、ひどいです。バリデーターは構成情報をイーサから引き出すため、単体テストを行うことはできません。
または、アプリ構成全体をコンストラクターでバリデーターに渡すこともできます。
$validator = new My_Validate_ValidateName($config);
少なくとも今、バリデーターをテストしたいときは、さまざまなオブジェクト/配列を渡すことができ、バリデーターが何か$config
に依存していることは明らかです。
しかし、これはバリデーターに必要以上の情報を与えていると思います。さらに、app-config からホワイトリストにアクセスする方法を知る必要があります。その情報はプロジェクトごとに異なる場合があります。いずれにせよ、バリデーターが電子メール アドレスのホワイトリストのみを必要とすることを直接確認するのは容易ではありません。
私の見解では、最良のことは次のとおりです。
$config = Zend_Registry::get('config');
$whitelist = $config['whitelist'];
$validator = new My_Validate_ValidateName($whitelist);
これで、バリデーターが必要とするものは明らかです。app-config からでも、リモート サービスからでも、どこからでも取得できます。バリデーターに必要なものを提供する責任があるのは、バリデーターの消費者です。
たとえば、そのバリデーターのコンシューマーがフォームである場合、フォームはそのホワイトリストを何らかの形で取得する方法を知る必要があります。同じ原則が適用されます。コンストラクターで必要なものを提供します。最終的にコントローラーレベルに到達したとき、私は自分自身を「アプリレベル」にいると考えています。その時点で、コントローラーが自分の app-config を見つけられる場所とその内部データへのアクセス方法を知っていることを期待して安心します。
私自身の見解です。YMMV。;-)
アップデート
場所に関しては、使用目的に基づいて配置する傾向があります。つまり、それらをプロジェクト間で使用する予定がある場合は、それらを に配置しますlibrary
。このアプリケーションでのみ使用する場合は、 に配置しますapplication
。