2

レガシー アプリケーションの複雑なフォームにいくつかの機能を追加しています。すでに、多数のコントロールとタブを備えた巨大なフォームと、巨大なコード ビハインド cs ファイルがあります。巨大なビュー/プレゼンターを作成することを避けようとしています。フォームの機能ごとにビュー (およびプレゼンター) を追加することは良い習慣ですか? より良い解決策はありますか？ユーザーの要求により、フォームを複数のフォームに分割することはできません。

フォーム定義は次のようになります。

public partial class frmMyForm 
    : IView1, IView2, IView3, IView4, IView5, 
      IView6, IView7, IView8, IView9, IView10
{
    ....

それぞれIViewNが異なる機能です。たとえば、1 つは視覚的なデータ変更比較用、1 つはグリッド内のデータの表示用、もう 1 つは要約統計用です...

この投稿が反対票を投じられているのはなぜですか? 理由をコメントしてください。MVP が何かわからない場合は、質問に反対票を投じないでください。

4

2 に答える 2

3

フォーム、ビュー、およびプレゼンターの間に 1 対 1 の関係があるとは言えません。実際、フォームのパーツを複数の「ビュー」に分割し (これはユーザー コントロールで最も頻繁に見られますが、必ずしもそうである必要はありません)、ビューごとにプレゼンターを配置することは、まったく合理的なことです。 . フォームがビューであることが最も一般的です。繰り返しますが、これは必須ではありません。

あなたが言うように、これは、よりまとまりのあるコードにつながり、単体テストの頭痛の種を減らすはずの、巨大なすべてを見る\すべてを行うプレゼンターを避けることを意味します。

于 2012-08-27T20:51:33.277 に答える
1

私の理解が正しければ、レガシー アプリケーションと既存の画面で作業していることになります。ここで、いくつかの新しい機能を追加する必要があります。その場合、追加するには、この画面で使用可能なモデル、プレゼンター、およびビューが既に存在している必要があります。その場合、新しい機能によって View と Presenter が巨大になる場合でも、同じアーキテクチャを使い続ける以外に選択肢はありません。

しかし、私が間違っていて、自分で画面を実装している場合は、独自のモデル、プレゼンター、およびビューを使用してユーザー コントロールを導入できます。ただし、ユーザーコントロールが互いに独立していることを確認してください。ユーザーコントロール間のブリッジを作成してそれらの間で通信することは、再び問題と混乱を招きます。

しかし、正直なところ、ファイルが巨大になっても、このタスクのために単一のプレゼンターとビューを作成することを好みます。通常、ユーザー コントロールは、複数の場所で使用できる共通のコントロールを作成するために使用されます。あなたのアプローチでは、作成しているユーザー コントロール間で多くの通信が行われている場合、トスが発生する可能性があります。しかし、はい、ユーザー コントロールが優れた計画で作成されていれば、これは緩和できます。しかし、私にとっては、密結合の状況でない限り、単一のプレゼンターとビューを持つことが好ましいです。また、resharper などのプラグインを利用している場合は、巨大なファイルが問題になることはありません。

于 2012-08-21T11:29:49.070 に答える