3

Project＃1には、project＃2が参照するいくつかのインターフェースとクラスがあります。

ここで、Project＃1でProject＃2の実装を使用したいのですが、vs.netは循環依存について文句を言います。

Project＃1で依存関係インジェクションを使用し、Project＃2の実装にバインドする場合（インターフェイスコントラクトに準拠しているため）、これは機能しますか、それとも実行時に循環依存関係エラーメッセージが表示されますか？

4

3 に答える 3

15

おそらくDIでこれを解決できますが、そうすべきではありません。

私の理解が正しければ、次のようなものがあります。

  + アセンブリ A + アセンブリ B
  | | | |
  +-- インターフェイス IFoo +-- クラス ConcreteFoo : IFoo
  | | ^
  +-- クラス MyClass -->------->-------|

MyClassつまり、参照を取得しようとしていますが、存在するConcreteFooassembly が既に in に依存しているため、取得できません。BConcreteFooIFooA

これは設計エラーです。IFooAssemblyでインターフェイスを宣言し、A具体的な実装を宣言しない場合、アセンブリ内の他のインターフェイス/クラスAはのみを参照IFooし、それを実装する具体的なクラスは参照しないでください。

循環依存を解消するには、次の 3 つの方法があります。

  1. の代わりにMyClass依存するようにします。可能であれば、これがおそらく最良の選択肢です。で使用するための の物理インスタンスが必要で、どこから取得すればよいかわからないという問題がある場合は、コンストラクターで を取得します。IFooConcreteFooIFooMyClassIFooMyClassIFoo

  2. インターフェイスを独自のアセンブリに移動します。これはまだかなり良い習慣です。デザインは次のようになります。

      + アセンブリ アプリ + アセンブリ インターフェイス + アセンブリ コンクリート
  | | | | | |
  | | +-- インターフェイス IFoo |
  | | | | \ |
  +-- クラス MyClass | \------+-- クラス ConcreteFoo
  | | | | | | ^
  +---- メンバー フー ->--------------------->------------------- | |

  3. MyClass独自のアセンブリに移動します。事実上、依存関係ツリーは上記の #2 と同じように見えますが、アセンブリAがそれよりもはるかに小さい場合B、必要な労力は少なくなります。

それが役立つことを願っています。

于 2010-01-12T23:31:13.537 に答える
8

多くの場合、Abstract Factory を使用して依存性注入 (DI) で循環依存性の問題を解決できます。例については、こちらを参照してください。

ただし、DI で問題を解決できる場合もありますが、API を再設計して循環依存をなくした方がよいでしょう。

多くの場合、エンドの 1 つをクエリ ベースの API からイベントベースの API に変更することで、循環依存関係を解消できます。

于 2010-01-12T23:05:22.423 に答える
1

Project1コードでProject1のクラスとインターフェイスのみを使用している限り、問題はありません。（依存性注入の構成は、プロジェクト1のコードベースの外部で行われると想定しています。）

しかし、循環依存の存在は、なぜそれが存在するのかを疑問視し、それを取り除く問題を解決する他の方法についての考えを促すはずです。

于 2010-01-12T22:51:19.390 に答える