DI / IoCコンテナーとファクトリー：アプリケーションをどこで構成するのか、そしてその理由は？

ソフトウェアの構成にDIC / IoCレジストリを使用するタイミングと、ファクトリを使用するタイミング、およびどちらのアプローチの背後にある理由も理解しようとしています。

レジストリを使用して簡単に構成できるDIコンテナー（DIC）としてStructureMapを使用しています。DICでは、実質的にすべての登録済みオブジェクトは静的です。つまり、DICが構成され、DICでシングルトンとして構成されたら、実行時に実装/インスタンスを変更/交換する必要はありません。ただし、ソフトウェア（SW）はさまざまなデバイスで実行されるため、ハードウェアを適切に構成するには、ソフトウェアが実行されるデバイスに応じてデバイス固有のレジストリを選択する必要があります。

一部のオブジェクトの構築には構成ファイルの読み取りが必要なため、構成の読み取りとオブジェクトの作成を分離するために、ファクトリを使用してこれらのインスタンスをDICに返しています。対応するプラグインタイプのファクトリゲッターをDICに登録しました。

IMotor具象型Motor1とを備えたプラグイン型があるとしましょうMotor2。これはファクトリで処理する必要があります。デバイスの構成方法を決定する方法は2つあります。

1. 私はSWが上に実行されていることをデバイスに関する情報を渡しMotorFactory、それが正しいモータを返す、のいずれかMotor1、またはMotor2。この場合、決定のロジックはファクトリー内にあります。
2. DICを実行しているデバイスに応じてDICを構成し、2つのファクトリMotor1Factoryを作成します。1 Motor2Factoryつは作成Motor1し、もう 1つは作成しますMotor2。この場合IMotor、Motor1Factoryまたはのいずれかを使用するデバイス固有のレジストリに、異なるレジストリエントリが含まれますMotor2Factory。

今私の質問です：これらの2つの方法のどちらが望ましいのですか？私には、コードベース全体でどのタイプをインスタンス化するかを決定するロジックを広げているため、最初のケースは単純ではなく複雑です。一方、2番目のケースでは、コード内のファクトリの数を効果的に増やしています。これは、（ほとんど）各具象型のファクトリが必要になるためです。抽象ファクトリーがミックスに追加されると、さらに混乱します。

繰り返しますが、どちらの方法を使用すればよいですか？さらに重要なのは、どちらの方法に進むかを決定するための優れた指標は何ですか？

両方を使用する場合、私は単純なものに行きます：

• DI / IoC：実行時に変更されないすべての構成。
• ファクトリ：実行時の入力パラメータに依存する実行時にオブジェクトのインスタンスを作成するため。ファクトリーのインスタンスは、DIコンテナーによって注入されます。

抽象ファクトリは、一緒に変化する必要がある階層を介して関連するオブジェクトがある場合に使用されます。ここでは見ません。

私が見ているのは、工場がモーターを選択する必要があるのか​​、またはDICが特定のモーターを生産する工場を選択する必要があるのか​​と疑問に思っているということです。

工場とDICは非常によく似ているため、正確に選択することは困難です。違いは、工場が特定の問題に焦点を当てており、DICがより一般的であることです。

それはこの質問に帰着します：あなたは、工場で生きるこの問題に特有のコードが必要ですか？それとも、ファイルから構成の詳細を読み取るような一般的なものですか？

Motor1との間だけを選択してMotor2いる場合でも、明日はが存在する可能性があることに注意してくださいMotor3。Motor3追加しやすいデザインを優先します。

「使用するモーター」というロジックをビルダー（パターン） と呼ばれる特別なファクトリーに分離し、ビルダーの実装の詳細として両方のモーターにIOCコンテナーを使用します。

原則として：

• クラス/インターフェースの動的オブジェクトを多数作成する必要がある場合は、ファクトリー（またはビルダー）が必要です。（つまり、生産するすべての車について、1つの新しいモーターを作成する必要があります）
• クラスの静的インスタンスが1つだけ必要な場合は、ioc / diが代わりにジョブを実行できます（つまり、paymentserviceの静的インスタンスが1つとMotorBuilderServiceの静的インスタンスが1つだけ必要です）。