さまざまな Web サイトで、依存関係の挿入を使用して .NET アセンブリ間の循環依存関係を解決することを提案している記事をいくつか見てきました。これはビルド エラーを解決するかもしれませんが、実際には循環依存関係を解決していませんよね? 私には、アーキテクチャにまだ論理的なエラーがあるようです。私は狂っていますか、それとも他の人は同意しますか?
- これは DI の優れた使用方法ではありませんか?
- 循環依存の問題を解決する適切な方法ではありませんか?
さまざまな Web サイトで、依存関係の挿入を使用して .NET アセンブリ間の循環依存関係を解決することを提案している記事をいくつか見てきました。これはビルド エラーを解決するかもしれませんが、実際には循環依存関係を解決していませんよね? 私には、アーキテクチャにまだ論理的なエラーがあるようです。私は狂っていますか、それとも他の人は同意しますか?
2 つのオブジェクト間に循環依存関係がある場合は、2 つのオブジェクトが依存する 3 番目のオブジェクトが必要であることを意味するため、相互に依存しません。あなたの問題に対する正確な解決策である記事は次のとおりです。
http://misko.hevery.com/2008/08/01/circular-dependency-in-constructors-and-dependency-injection/
同じ答えが次の投稿 (参照用に追加します) に返されます。これは、両方が依存する 3 番目のクラスを作成します。つまり、単一責任の原則に違反しています。両方のクラスが依存する責任を別のクラスに移動 (抽出) することにより、循環依存関係を削除します。
参考までにウィキペディアの単一責任パターン
他の人による StackOverflow の議論:
別のクラスで責任を抽出する例を含む StackOverflow に関する私の回答。
DI は循環依存関係の解決のためではなく、適切に分離されたコンポーネントの作成を容易にし、よりテストしやすいコンポーネントを作成するためのものです。
「周期的依存関係の削除」を検索してこの役立つ投稿を見つけたので、ここに 0.02 ドルを投入します。
はい。DI を使用して、循環依存関係を解決できます。問題を修正するための最初のステップは、問題を見つけることです。Ninject は、私の循環依存関係について不平を言い、ブートストラップ時に役立つ例外をスローしました。Ninject は私のためにそれを見つけ、私にそれを修正するように強制しています。プロパティインジェクションまたはメソッドインジェクションをごまかして使用することはできますが、それはクラス不変条件の保護を破ります(これはあなたが不満を言っていることだと思います)。
したがって、IoC を介した ctor インジェクションに投票してください。循環依存関係が検出されるからです。その後、アーキテクチャのバグをリファクタリングして削除するのはあなた次第です。