私はASP.NET MVCを使い、同時にDIと依存関係の逆転を学んでいます。私はコントローラとビューが1つのアセンブリにあるMVCプロジェクトに立ち上げています。また、実際のビジネスロジックのほとんどに対応するドメインモデルとサービス用のアセンブリが2つあります。依存関係の反転 - インタフェースの所有者ですか？
私のすべてのサービスにインターフェイスを実装する予定です。サービスを呼び出すコントローラーは、これらのインターフェースを介してアクセスします。インスタンス化は、Ninject DIフレームワークを使用して行われます。
実際の質問です。誰がインタフェースを所有していますか？依存関係の逆転の私の理解から、サービスインタフェースはコントローラによって所有され、したがってそのアセンブリに常駐します。
なしは自身インターフェイスに持っています。優れたインターフェイスは独自の動物です。コントローラーとサービスの両方に見えるようにするだけです。
物理的に分離するcreates headaches that may be unnecessary - 正当な理由なく複数のアセンブリを使用しないことをお勧めします。
依存性の逆転についての私の理解; 「通常」の依存関係では、下位レベルのコンポーネントは機能を指定し、上位のコンポーネントはこれらの仕様に依存します。逆の依存関係では、上位のコンポーネントは、下位レベルのコンポーネント、つまり実装する必要があるインターフェイスからのニーズを指定します。これは、上位コンポーネントがインターフェイスを「所有」していることを意味します。それは理にかなっていますか？もちろん、これはインターフェイスが同じアセンブリ/モジュール/それ以上のレベルのコンポーネントとして存在する必要があることを意味する必要はありません。 –
私はあなたがここで自分のことを本当に理解していないと思います。所有権はいつ問題になるでしょうか？うまく設計されたインターフェースは、多くの場合、複数の消費者によって使用されることになり、その場合、単一の所有者はいない。 –
インターフェイスは、実装者に見える必要があります。この実装は、消費者に見えるかもしれない。インプリメンテーションを別々に配備できるようにインプリメンテーションをインタフェースから分離したい場合、インターフェースはそれぞれのアセンブリに存在する必要があります。
名前空間に基づいてコードを整理し、特別な展開要件がない場合は、実装と同じアセンブリにインターフェイスを置くことができます。
仮想-1。 「この実装は消費者に見えるかもしれない」 - >間違って – Aliostad
はいそうかもしれません。あなたは、インターフェイスを分離しなければならないと言い、異なる展開アーチファクトに含意しなければならない、あるいはあなたのimplsが内部でなければならない、あるいはそうでなければ隠されていなければならないというルールはありません。だから私は規律を言う。 DIの問題を有効にして、同じアセンブリ内にimplsとinterfaceを持つことができます。それはすべて、展開のニーズに依存します。私はいつも顧客とこの問題を抱えています。プロジェクトは、デプロイメントのアーチファクトであり、コード構成と品質イネーブラーではありません。 – flq
サービスへのインターフェイス（通常はデータを提供し、WCFとして実装する必要があります）は別のDLLに置く必要があり、MVCには参照があります。だからここ
プロジェクト（およびアセンブリ）へのクラスおよびインタフェースの典型的な（と基本的な）分割です：
なぜインタフェースを含むための「拡張性」のために別のアセンブリを使用しないのですか？ –
可能な重複：http://stackoverflow.com/questions/1731515/dependency-injection-who-owns-the-interface –
重複：http://stackoverflow.com/questions/2401466/how-to-structure-interfaces-アプリケーションディレクトリ階層内 –