[解決済み] Ioc/DI - なぜアプリケーションのエントリポイントですべてのレイヤー/アセンブリを参照しなければならないのですか?
質問
(この質問と関連するもの EF4:レイジーローディングが有効なとき、なぜプロキシ作成が有効でなければならないのですか? ).
私はDI初心者なので、ご容赦ください。私は、コンテナが私の登録されたタイプのすべてのインスタンス化を担当することを理解していますが、そうするためには、私のソリューションのすべてのDLLとその参照への参照を必要とします。
DIコンテナを使用していない場合、私はMVC3アプリでEntityFrameworkライブラリを参照する必要はなく、ビジネス層のみを参照し、DAL/Repo層を参照することになるでしょう。
最終的にすべての DLL が bin フォルダに含まれることは知っていますが、私の問題は、すべての必要なファイルを含む WAP を発行できるようにするために、VS で "add reference" によって明示的にそれを参照しなければならないことです。
どのように解決するのですか。
DIコンテナを使用していない場合、MVC3アプリでEntityFrameworkライブラリを参照する必要はなく、ビジネス層だけがDAL/Repo層を参照することになります。
そうですね、まさにDIはそのような状況を避けるために一生懸命働いていますね :)
密結合されたコードでは、各ライブラリは数個の参照しか持たないかもしれませんが、そのライブラリにはまた別の参照があり、このように深い依存関係のグラフが形成されるのです。
依存関係グラフは深いので、ほとんどのライブラリは他の多くの依存関係を引きずっていることを意味します - たとえば図のように。 ライブラリ C は 図書館H、図書館E、図書館J、図書館M、図書館K と 図書館N . このため、各ライブラリを独立して再利用することが難しくなります - 例えば ユニットテストでは .
しかし、疎結合のアプリケーションでは、すべての参照を コンポジションルート に移動させることで 依存関係グラフが著しく平坦化される :
緑色で示されているように、再利用が可能になりました。 ライブラリ C を、不要な依存関係を引きずることなく再利用できるようになりました。
しかし、多くのDIコンテナでは を持つ を使用して、必要なライブラリにハードリファレンスを追加する必要はありません。その代わりに レイトバインディング を、規約ベースのアセンブリスキャン(推奨)またはXML設定の形で使用します。
しかし、それを行うとき、もはや自動的に行われないので、アプリケーションの bin フォルダーにアセンブリをコピーすることを忘れてはなりません。個人的には、そのような余分な労力をかける価値があることはほとんどないと思います。
この回答のより詳細なバージョンは、次のサイトで見ることができます。 この抜粋 私の本から 依存性注入、原則、プラクティス、パターン .
関連
最新
-
nginxです。[emerg] 0.0.0.0:80 への bind() に失敗しました (98: アドレスは既に使用中です)
-
htmlページでギリシャ文字を使うには
-
ピュアhtml+cssでの要素読み込み効果
-
純粋なhtml + cssで五輪を実現するサンプルコード
-
ナビゲーションバー・ドロップダウンメニューのHTML+CSSサンプルコード
-
タイピング効果を実現するピュアhtml+css
-
htmlの選択ボックスのプレースホルダー作成に関する質問
-
html css3 伸縮しない 画像表示効果
-
トップナビゲーションバーメニュー作成用HTML+CSS
-
html+css 実装 サイバーパンク風ボタン