3

わかりましたので、依存性注入コンテナーと、次のように注文を取得するために使用する DAO があります。

$container = new DIContainer();
$orderDAO = $container->get('orderDAO');
$order = $orderDAO->fetchById($someId);

そして、使いやすい注文オブジェクトがあります。

問題は、$orderオブジェクトが に依存している場合Logger、Configおよびそのようなオブジェクトが 1 つまたは 2 つある場合です。$orderDAOオブジェクトをインスタンス化すると、それらの追加のオブジェクトにアクセスしたり作成したりする必要がなくなり、$orderDAOオブジェクトがこれらの追加オブジェクトについて何も知らないはずです。特に、それらを作成する方法を知っている必要はありません。

インスタンス化されているときに (DIC 内から) 依存性注入コンテナーを DAO に注入できることはわかっています。そうすれば、オブジェクトが DAO 内から持っている依存関係にアクセスできますが、そのようにすることについて何かがうまくいきません。なんらかの理由で私には正しいと感じており、メソッドが窓の外にあるように、どこでも静的呼び出しを行いたくありません。

これを行う最善の方法は何ですか？

どんな助けでも大歓迎です。

4

1 に答える 1

0

インスタンス化するオブジェクト内でLogger、Configなどを割り当てるなど、DIコンテナが内部オブジェクトの依存関係を管理できるようにすることは、通常の方法です。何らかの理由で DI コンテナーにそれを許可したくない場合は、デフォルトのコンストラクターを作成して、この値を代入することができます。

実際には、いくつかのインフラストラクチャを内部に配置する必要があるように見えます。そのように、余分なものを追加せずにできるだけ単純にすることをお勧めします。不必要に複雑になるからです。

更新:

そのため、productDAO には Config などへのアクセス権がありません...しかし、その製品にはそれが必要です。設計の観点からはかなり間違っていると思います。通常、主な目的がデータの保存であるエンティティは、ビジネス ロジック以外の機能を持つべきではないためです。ロギングと構成を行いたくない場合は、製品ではなく DAO 内で行う必要があります。とにかく、必要に応じて、将来変更される可能性のあるもの（Loggerとしましょう）のラッパーを作成し、コンストラクターでこの値を手動で割り当てるだけです。

于 2013-01-29T20:21:42.080 に答える