個々のサービスの代わりにサービスコンテナを注入しないようにする技術的な理由は何ですか？

Question

通常、1つ以上のサービスを別のサービスに注入する必要があるときは、それぞれを明示的に注入します。しかし、私は、サービスコンテナ自体を注入することによって、実際の作業がより簡単になるという状況があります。私はこれが推奨される習慣ではないことを知っていますが、私は技術的な理由がこれを落胆させることであるのは不思議です。それはあまりにもリソースを集中しているような正当な何か、またはそれはあまりにも面倒なより個人的な感じですか？

Answer 1

コンテナを注入する場合は、依存関係をクリアしていません。実際、あなたは以前よりもそれらをあいまいにしています。あなたはこのようなクラスを持っている場合は...

class DocumentCreator(IFileNamer fileNamer, IRepository repository) 
{ ... } 

...あなたは依存関係が何であるかを見ることができます。また、単体テストのためにそれらの依存関係を簡単に疑似して、DocumentCreatorを分離し、テストの失敗がその依存関係の1つではなくコードの結果であることを知ることができます。

場合は、他の一方で、あなたがこれを行う...

class DocumentCreator(IDependencyContainer container) 
{ ... } 

は...あなたは依存関係を曖昧にしました。あなたは、クラスの内部を調べることなく、IFileNamerとIRepositoryが必要であることを知ることはできません。

DocumentCreatorをテストするために、コンテナに入れる必要のある模様を簡単に知ることはできません。 IDependencyContainerを嘲笑しても、あなたを助けません。 IForeNamerとIRepositoryがコンテナに含まれないため、クラスの内部を調べて必要がないことを確認しない限り、クラスはテストに失敗します。

Answer 2

私はこのアプローチの主な問題は、もはや依存関係をはっきりと見ないということです。別の問題は、テストするのがより難しいことかもしれません。

Answer 3

あなたが説明するものはServiceLocatorです。これは、最新のアプリケーション設計における反パターンと考えられています。なぜThis articleに記載されています。