IoCの上に抽象的なファクトリパターン？
より大きなプロジェクトではIoCの原則を使用することにしました。でも、ずっと気になってたまっすぐなものにしたいです。私が思いついた結論は、IoCコンテナーはアーキテクチャパターンであり、デザインパターンではないということです。言い換えると、クラスはその存在を認識してはならず、コンテナ自体をアプリケーション層で使用してすべてのコンポーネントを結合する必要があります。基本的に、適切に設計されたオブジェクト指向モデルに加えて、これはオプションになります。そうは言っても、IoCコンテナーを（抽象化されているかどうかに関係なく）あちこちに散らかさずに解決された型にアクセスするにはどうすればよいでしょうか。ここで私が見る唯一のオプションは、IoCコンテナを使用して具象型を解決する抽象ファクトリを利用することです。これは、一連の標準的なファクトリーと交換するのに十分簡単なはずです。これは良いアプローチですか？ここで誰かがそれを使用しましたか、それはあなたにとってどれほどうまくいきましたか？他に何かありますか？
ありがとう！
あなたがすでに理解しているように、依存性注入（DI）自体はパターンとテクニックのコレクションにすぎません。
アプリケーションのルートで、必要なすべてのオブジェクトグラフを結び付けます。この場所は Composition Root と呼ばれ、DIコンテナを使用してこの配線を行うことも、手動で行うこともできます（ Pure DI ）。
重要なのは、特定のテクノロジー（DIコンテナー）への強い参照があるアプリケーションの場所は1つしかないということです。アプリの残りの部分は、幸いにもhowオブジェクトグラフが関連付けられていることを認識していません-重要なのは、必要なすべての依存関係が正しく注入されたことです（そしてを使用できます）注入とNull Guardsを使用してこれを保証します）。
Abstract Factoryパターンは、DIに関してはvery有用なパターンです。本質的には、次の場合にAbstract Factoryを使用します。
- 依存関係を解決する前に、実行時にのみ既知の1つ以上のパラメーターを指定する必要があります。
- 依存関係の存続期間は、概念的にはコンシューマーの存続期間よりも短くなります。
例と詳細情報はここにあります：
アプリケーションの最上部には、Bootstrapクラスをロードするクラスが必要です。IOCコンテキスト。このコンテキストは、実際にインスタンス化されたオブジェクトを提供するため、工場として機能します。
ただし、これは非常に少数のオブジェクトでのみ発生するはずであり、Bootstrap/Factoryクラスのユーザーは、基礎となるアーキテクチャーについて可能な限りほとんど知らないはずです。たとえば、IOCを介して完全にHTTPサーバーオブジェクトを構成し、それを起動したい場合、BootstrapクラスはgetHttpServer（）メソッドを提供するだけで十分です。次にプログラムのメインメソッドは、Bootstrap.getHttpServer（）。start（）を呼び出して実行するだけです。
他のオブジェクトの関連付けは、アプリケーションコンテキストによって既に行われています。 IOCオブジェクトBの一部であるオブジェクトAを構成するため、オブジェクトAへの参照を使用してオブジェクトBを構成します。通常は、コンテナーもファクトリーも知る必要はありません。