アプリケーションを緩く結合するという観点から、IoCの実装をどこまで進めるべきか疑問に思いました。MVCコントローラーでコンストラクターインジェクションを使用していますが、オブジェクトを更新する代わりに、コントローラー内の他のすべての依存関係も解決する必要があるかどうか疑問に思いました。たとえば、コントローラーメソッド内に新しいUserオブジェクトを作成する場合、使用しますか？
var user = new User();
var user = myContainer.Resolve<IUser>();
Userへの依存を解消するというアイデアは気に入っていますが、それが行き過ぎてコードが読みにくくなる可能性はありますか？
これは非常に良い質問です。DIについて読んだり聞いたりすると、それは理にかなっており、これが次の自然な結論です。
最初のスティーブンのポイントは正しいです、あなたはコンテナを回してはいけません。その場でIUserを構築する必要があり、それを抽象化する必要がある場合は、抽象ファクトリを注入する必要があります。
セバスチャンも良いリンクを投稿しました。
私は実際にここに投稿した回答でこれについて書きました。
投稿の下部：
すべてのオブジェクトと依存関係に依存性を注入する必要がある、または注入する必要があるわけではありません。まず、使用しているものが実際に依存性と見なされるかどうかを検討してください。
依存関係とは何ですか？
Application Configuration
System Resources (Clock)
Third Party Libraries
Database
WCF/Network Services
External Systems (File/Email)
上記のオブジェクトまたは共同作業者は、制御不能になり、副作用や動作の違いを引き起こし、テストを困難にする可能性があります。これらは、抽象化（クラス/インターフェース）を検討し、DIを使用するときです。
依存関係ではないもの、本当にDIを必要としないものは何ですか？
List
MemoryStream
Strings/Primitives
Leaf Objects/Dto's
したがって、特定のケースでは、IUserが構築されたときに何が起こるか、また実際にそれを別の実装に置き換える必要があるかどうかによっても異なります。これが当てはまらず、ユーザーが外部依存関係や副作用のない単純なタイプしかない場合は、それを新しくします。
new User（）を呼び出すとどうなるかを考えてください。下のグラフを見てください。他のオブジェクトが作成され、下のグラフのように見える場合は、IoCを検討してください。
カスケード依存関係オブジェクトグラフ：
この例では、オブジェクトのnewは、他の多くの依存関係を必要とするか、作成します。これらの依存関係が何であるか、または何をするかは、ほとんどの場合、制御できません。
オブジェクトが単純なdtoの場合、この問題は発生せず、IoCはそれほど必要ない可能性があります。