循環依存関係

Question

WinForms を使用した MVC パターンに基づく通常の顧客注文アプリケーションを考えてみましょう。ビュー部分が大きくなりすぎている (4000 ファイルを超えている) ため、より小さなファイルに分割する必要があります。

---

この例では、ビュー部分に 3 つのプロジェクトを使用します。

• 主要 - 他の 2 つのプロジェクトへの依存関係があります。リストを使用してフォームをインスタンス化します。
• お客様 - 顧客リストと顧客詳細の 2 つのフォームがあります。
• 注文 - 注文リストと注文詳細の 2 つのフォームがあります。

---

顧客詳細フォームには、その顧客の注文のリストもあります。リストは OrdersController から取得されるので、問題なく取得できます。ユーザーが注文を選択すると、リストはその GUID を取得し、参照として注文詳細フォームに渡します。

これは、Customers プロジェクト内に Orders プロジェクトへの参照が必要であることを意味します。 (1)

ただし、注文詳細フォームには、その注文を行った顧客へのリンクもあります。クリックすると、顧客詳細フォームが開きます。

これは、Orders プロジェクト内に Customers プロジェクトへの参照が必要であることを意味します。 (2)

(1) と (2) から、Orders プロジェクトと Customers プロジェクトの間に循環依存関係が存在します。

---

どうすればこれを回避できるでしょうか? ある種のプラグイン アーキテクチャでしょうか?プロジェクトはすでに開発されており、最善の解決策はコードの変更をできるだけ少なくすることです。

Answer 1

少なくとも 1 つのタイプをインターフェースに変更します。

たとえば、ICustomer インターフェイスと、このインターフェイスを実装する Customer 型があります。次に、ICustomer をorders プロジェクトに追加し、customers プロジェクトから Orders プロジェクトへの参照を設定して、インターフェイスを実装できるようにします。Order タイプは、実際の実装を知らなくても ICustomer タイプに対して機能できるようになりました。

そして、より良い解決策のために:-) ICUSTOMERとIORDERインターフェイスの両方を作成し、それらを第3ライブラリプロジェクトに追加します。そして、他の 2 つのプロジェクトからこのプロジェクトを参照し、実装ではなくインターフェイスのみを操作します。

Answer 2

それほど緊密に結合されている場合は、分割すべきではないかもしれません。

Answer 3

インターフェイスを抽出し、別のアセンブリに配置します。MVC アーキテクチャを使用しているため、難しいことではありません。例と優れた実践例については、Microsoft Composite UI Applications ブロックを参照してください。

Answer 4

あなたの主な問題はアプリケーションのアーキテクチャではないと思います。境界と、境界間で機能を分割する方法を理解する必要があります。あなたのような分割は非常に人為的であり、ドメインオブジェクトに基づいてアプリケーションを分割しようとしています。ユーザー ロールまたは機能テーマを使用してみると、問題が解決する可能性があります。

技術的な観点から見ると、なぜあなたのビューがお互いの存在を認識しなければならないのかわかりません。それは私には少し奇妙に聞こえます。データとビジネス ロジックを分割するつもりはありません。結局のところ、GUID は、さまざまな方法を使用して簡単に渡せる単なる文字列にすぎません。