IoCとDIビジネスには新しくあります。グローバルスコープのオブジェクトを渡していると思っていますが、特定の論理状態のオブジェクトを渡す必要がある場合の動作方法。たとえば、人物オブジェクトを書き込みファイルのコマンドオブジェクトに挿入する場合、正しい人物オブジェクトを動的に選択するにはどうすればよいでしょうか？私が見たことから、オブジェクトをデフォルトで構築することができますが、私の切断は、デフォルトのpersonオブジェクトを使用しないことです。動的である必要があります。私は、IoCコンテナが渡されたときにオブジェクトの状態を維持するだけかもしれないと仮定していますが、スレッド安全性がないため、1人のオブジェクトだけを扱っていると確信しています。私は何かが不足していることを知っています（factoryclassのようなものかもしれません）。しかし、それがどう機能するかについてもう少し詳しく知る必要があります。ステートフルなオブジェクト（グローバルではない）のIoC依存性注入
よく、あなたはコンシューマにいつもAbstract Factoryを注入し、それを使ってローカルスコープのオブジェクトを作成できます。
これは時には必要です。これらの例を参照してください。
しかし、一般的に私たちは、ほとんどが、サービスのために、エンティティのためのDIを使用しない傾向にあります。代わりに、エンティティは通常、何らかのリポジトリを介して作成されます。
サービスオブジェクト（たとえば、WriteFileService）を作成するときは、そのジョブを完了するために内部的に必要なものを注入します。ファイルシステムオブジェクトなどが必要なのかもしれません。
例のPersonオブジェクトは、メソッド呼び出しのパラメータとしてサービスオブジェクトに渡す必要があります。例えばwriteFileService.write(person)
Entity PersonオブジェクトにWriteFileServiceを挿入しないでください...この場合、DIインフラストラクチャなしでEntityがどのように使用されるのかがわかります。 WriteFileServiceは、DIインフラストラクチャが作成されたときにDIインフラストラクチャを使用した可能性があります（特定の出力に書き込む注入されたクラスの必要性に基づいています。WriterA - データベースへの書き込み、WriterB - コンソールへの権限など）。 – mytwocents
一般に、エンティティはDIインフラストラクチャの一部ではありませんか？私はこれを複雑にしていますか？ – mytwocents
そうです。エンティティとバリューオブジェクトは別々の生活を送る傾向があります。ある意味では、彼らはまだDIインフラストラクチャによって管理されています（理想的にはすべてがあります）が、間接的な方法で管理されています。これらは通常、リポジトリなどを介して永続ストレージに読み書きされます。*これらは、DIインフラストラクチャの一部であるサービスです。 –
私はDIのプリンシパルが、EnitityオブジェクトをIoCコンテナから（コンフィグレーション経由で）利用可能にする必要があると言っていたと思っています... – mytwocents