このブログ投稿$this->getServiceLocator()では、コントローラー内を避けるべき 3 つの理由を読むことができます。これらの理由は、コントローラー クラスだけでなく、インターフェイスを実装するどのクラスでも有効だと思いServiceLocatorAwareInterfaceます。
ServiceLocatorAwareInterfaceほとんどの場合、 ?を使用して依存関係を注入するアンチ パターンと見なされます。このパターンがアンチパターンと見なされないのはどのような場合で、その理由は?
代替ソリューション（おそらくZend \ DIを使用すると思います）がどのようになるかについて、誰か詳しく説明できますか？より具体的には、ServiceLocatorAwareInterface Modules、Controllers、およびBusiness/Domainクラスの使用を回避する方法。Zend\DI とその解決策に関するパフォーマンスの問題について知りたいです。
編集
$this->getServiceLocator()->get($serviceName)テストの問題をまったく解決せずに「インジェクターコード」（以前の）をファクトリーに移動するだけで最後に得られる場合、2つまたは3つの依存関係を持つクラスのファクトリーを定義する価値がありますか？もちろん、工場もテストしたいですか？それともいいえ？
ファクトリは、オブジェクトのビルドが複雑なタスクを伴う状況に限定する必要があると思います。クラスの依存関係がほとんどなく、(依存関係の解決以外に) ロジックがゼロの場合、ファクトリ ソリューションはこの問題のやり過ぎだと私には思えます。さらに、このソリューションでは、テスト実装のコードが少なくならないようにしながら、テスト (ファクトリ) のコードとテスト (ファクトリのテスト) を増やすことで終了します。サービス ロケータのモックは簡単です。インターフェイスには 2 つのメソッドしかなく、すべてのテスト ケース間でモック コードを共有できるからです。
Pls、間違っていたら訂正してください;)
Zend\DIが役に立ちますが、誰かがこの種のソリューションの詳細について詳しく説明してくれれば幸いです。
編集2
数週間前、このZend ウェビナー (「ZF2 を使用したドメイン駆動設計の概要」) では、このアンチパターンが使用されました (39:05)。私は今、これが本当にアンチパターンになるまでさまよっています;）
そして、ここにこの問題に関する詳細情報があります。
ファウラーが言わなければならないことはここにあります