（この質問に関連して、EF4: 遅延読み込みが有効になっているときにプロキシ作成を有効にする必要があるのはなぜですか?）。
私は DI の初心者なので、ご容赦ください。コンテナーが登録されているすべての型のインスタンス化を担当していることは理解していますが、そのためにはソリューション内のすべての DLL への参照とその参照が必要です。
DI コンテナーを使用していなければ、MVC3 アプリで EntityFramework ライブラリを参照する必要はなく、DAL/Repo レイヤーを参照するビジネス レイヤーのみを参照することになります。
最終的にはすべての DLL が bin フォルダーに含まれていることはわかっていますが、必要なすべてのファイルを含む WAP を公開できるようにするために、VS で「参照の追加」を介して明示的に参照する必要があるのが問題です。
ベストアンサー1
DI コンテナーを使用していなければ、MVC3 アプリで EntityFramework ライブラリを参照する必要はなく、DAL/Repo レイヤーを参照するビジネス レイヤーのみを参照すればよいことになります。
はい、それはまさに DI が懸命に回避しようとしている状況です :)
密結合コードでは、各ライブラリには参照がいくつかあるだけですが、これらにはさらに別の参照があり、次のような依存関係の深いグラフが作成されます。
依存関係グラフが深いため、ほとんどのライブラリは他の多くの依存関係を引きずっていることになります。たとえば、図では、図書館C引きずる図書館H、図書館E、図書館J、図書館M、図書館Kそして図書館Nこれにより、各ライブラリを他のライブラリから独立して再利用することが難しくなります。たとえば、ユニットテスト。
しかし、疎結合アプリケーションでは、すべての参照を構成ルート、依存関係グラフは著しく平坦化されている:
緑色で示されているように、再利用が可能になりました図書館C不要な依存関係を引きずることなく。
しかし、多くのDIコンテナでは、持っている必要なすべてのライブラリへのハード参照を追加します。代わりに、遅延バインディング規則ベースのアセンブリスキャン形式（推奨）または XML 構成のいずれかです。
ただし、これを行う場合は、アセンブリをアプリケーションの bin フォルダーにコピーすることを忘れないようにしてください。これは自動的に行われなくなるためです。個人的には、その余分な労力をかける価値があるとはほとんど思いません。
この回答のより詳しいバージョンは、この抜粋私の本から依存性注入、原則、実践、パターン。