6

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

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

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

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

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

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

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

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

どうすればこれを回避できますか? ある種のプラグイン アーキテクチャ？プロジェクトはすでに開発されており、最適なソリューションはコードの変更をできるだけ少なくすることです。

4

4 に答える 4

6

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

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

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

于 2008-09-23T13:23:01.037 に答える
1

それらが密結合している場合は、分割しないでください。

于 2008-09-23T13:20:21.527 に答える
0

インターフェイスを抽出し、別々のアセンブリに配置します。MVCアーキテクチャを使用しているので、難しいことではありません。例とグッドプラクティスについては、MicrosoftCompositeUIアプリケーションブロックを参照してください。

于 2008-09-23T13:22:13.160 に答える
0

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

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

于 2008-09-23T13:27:30.590 に答える