依存性注入にServiceLocatorを使用すべきではないと人々が言うのを聞いています。では、サービスロケーターに依存せずに、どの程度正確に依存関係を注入しますか？IoCコンテナーを試してみたいのですが、アンチパターンに陥りたくありません。
すべてのクラスが常に最も深いクラスへの依存関係チェーンを持つ1つの場所があるように、すべてを設定する必要がありますか？（私/それがまったく理にかなっている場合）
選択したIoCコンテナへの依存関係ですべてのコードを散らかすのは正しくありませんか？
では、コンテナをどこで「使用」しますか（再解決のため）？そして、コードが進む限り、どのようにしてすべてを解決することができますか？それは、フロントレイヤーまでのすべてのレイヤーを介してインターフェイスを使用することにより、すべてを正しい方法で設計することの一部ですか？
それとも私はただポイントを逃していますか？
私はアンチパターンに陥りたくないので、いくつかのヒント/注意が必要であることを思い出させてください。
すべてのクラスが常に最も深いクラスへの依存関係チェーンを持つ1つの場所があるように、すべてを設定する必要がありますか？（私/それがまったく理にかなっている場合）
はい、これはアプリケーションのコンポジションルートと呼ばれ、 IoCコンテナを構成してルートタイプを解決する場所です。
選択したIoCコンテナへの依存関係ですべてのコードを散らかすのは正しくありませんか？
正解です。タイプの周りにIoCコンテナーへの参照を渡さない方がよいでしょう。これにより、タイプの再利用性が低下し、タイプを一般的なIoCコンテナーの概念に結合します。
では、コンテナをどこで「使用」しますか（再解決のため）？そして、コードが進む限り、どのようにしてすべてを解決することができますか？それは、フロントレイヤーまでのすべてのレイヤーを介してインターフェイスを使用することにより、すべてを正しい方法で設計することの一部ですか？
コンポジションルートでコンテナを使用し、コンテナを介して（通常は依存関係チェーンのサポートのために）型をインスタンス化する必要があるコード内の任意の場所で使用します（つまり、ファクトリ型から）。
多くのIoCコンテナは、これらのファクトリタイプを生成できるため、たとえばIMyFactory依存関係として、または一部のIoCコンテナの場合は、を渡すだけで済みFunc<IMyService>ます。つまり、IoCコンテナに依存するファクトリタイプを作成する必要はありません。
インターフェースの使用に関して、依存性逆転の原則は、具体化ではなく抽象化に依存する必要があると述べているため、依存性注入を採用する場合は、この概念を念頭に置いてコードを因数分解する必要があります。