39

私は2つの関連する（この質問に）プロジェクトと他のいくつかのプロジェクトで解決策を持っています。

  1. 他のいくつかのプロジェクトで使用される機能を備えたクラスライブラリ。
  2. ASP.NETMVCアプリケーション。

私の質問は基本的に、Ninject2でIoCをどこ​​で行うべきかということです...

  • クラスライブラリには、特にWebリクエスト固有のセッションオブジェクトを必要とするリポジトリクラス内のDIの愛が必要です（作業ユニットを考えてください）。
  • Ninject 2では基本的にNinjectHttpApplicationから継承するため、MVCアプリにはDIが必要です。
  • クラスライブラリの単体テストでは、別のリポジトリセットを挿入するために、これを認識する必要があります。
  • 同じ理由で、Webアプリの単体テストを挿入する必要があります。

そもそも3つの選択肢しか見られなかったので、私はここで自分自身を精神的なコーナーに塗りつぶしました。クラスライブラリのDI、WebアプリのDI、またはその両方ですが、それぞれに問題があります。

  • そもそもMVCアプリはNinjectHttpApplicationから継承する必要があるため、クラスライブラリでのみDIを実行することはできません。
  • 私はMVCアプリでのみDIを実行することはできません-結局のところ、クラスライブラリは他のライブラリによって使用されており、MVCアプリはとにかくライブラリの内部についてあまり知らないはずです。
  • これが私が見ることができる唯一の方法だと思います：両方のプロジェクトの独立したIoC。クラスライブラリとMVCアプリには、それぞれ独自のIoCセットアップがあり、お互いを気にすることなく、自分たちのもののDIを実行します。

誰かがこのようなことをする方法に関するいくつかの「ベストプラクティス」またはガイドラインを持っていますか？私がこのような状況に陥った最初の人だとは想像できません。これを行うための「適切な」方法が何であるかを知っておくとよいでしょう...

ありがとう！

4

1 に答える 1

64

NInject についてはわかりませんが、Windsor や StructureMap などと大きく異なる動作をしない限り、いくつかの一般的な DI パターンがあるため、答えは同じままになる傾向があります。それを念頭に置いて：

最初に認識すべきことは、DI は NInject や Windsor などの特定のフレームワークに結び付けられていないということです。これは、従うべき一連の手法と設計パターンです。いわゆる貧乏人の DI を使用して手動で DI を実行できますが、明らかに DI コンテナーを使用するとはるかに優れたものになります。

なぜこれが関連するのですか？これを認識すると、結果として、アプリケーションのコードの大部分はDI コンテナーの知識を一切持たないはずなので、これは重要です。

では、DI コンテナーはどこで使用するのでしょうか。これは、あなたの場合は Global.asax に対応するComposition Rootでのみ使用する必要があります。これについては、この SO 回答でもう少し読むことができます。その質問はウィンザーに関するものですが、原則は同じままです。

ユニットテストはどうですか？DI コンテナについても完全に無知であるべきです。詳細については、この他の SO の回答を参照してください。

DI は、Constructor Injectionを多用してライブラリで実現できます。そのために DI コンテナーを参照する必要はありませんが、DI コンテナーを使用してコンポジション ルートからすべての依存関係を解決すると、作業がずっと楽になります。

于 2009-09-25T07:15:43.120 に答える