3

最近よくある問題の1つは、プレゼンターのクラスが大きくなりすぎるという問題です。通常、私はビートをスキップすることなく、通常の大規模なクラスを切り刻むことができます。ただし、プレゼンターは、コードを理解しにくくすることなく、整理するのが少し難しい場合があります。

特に、ページがCRUD指向のコントロールでいっぱいになり始めたとき。コントロールを分割することもありますが、他のコントロールの影響を受ける場合、調整ロジックはそれ自体が複雑です。リストまたはグリッドデータの取得を分割することもありますが、同様の落とし穴がある場合もあります。

プレゼンターからリファクタリングするテクニック、経験則、または一般的な領域はありますか？

4

2 に答える 2

9

私は通常2つのアプローチを使用します：

  1. ビジネスルールを抽出してドメインクラスに委任します。
  2. ビューを論理的に関連するコントロールに分割してから、パーティションごとに新しいビューインターフェイスを作成します。次に、プレゼンターを同じ線に沿って分割できます。使用しているプラ​​ットフォームがサブフォームコンポーネントグループ（C＃ユーザーコントロール、Delphiフレームなど）をサポートしている場合、これは再利用可能なコントロールを作成するための強力な方法です。

アップデート

ビューを分割するとき、私は通常、インターフェイスを分割し、フォームに複数のインターフェイスを実装させることから始めます。

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

次に、プレゼンターを、作成したビューの数に分割します。

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

さらに一歩進んで、ISubViewとIOtherSubViewの実装をユーザーコントロールに移動するか、そのままにしておくことができます。パッシブビューパターンを使用している場合、フォームはUIロジックのみを処理するため、これは子供の遊びです。プレゼンターを分割した後は、プレゼンター間の直接のコミュニケーションを避けようとします。通信が必要な場合は、ドメインオブジェクトを介して間接的に通信を試みます。

于 2009-05-07T16:58:39.240 に答える
3

データをDALに渡したり、ビューにプッシュしたりする以外のアクティビティを実行するコードを抽出してみてください。たとえば、電子メールの更新やビジネスロジックの実行が必要な場合は、それらを別々のクラスに抽出してみてください。私はよく同じ問題に対処し、可能な限り多くのロジックを個々のドメイン/エンティティクラスに移動し、そこで検証を実行しようとしています。

これがお役に立てば幸いです。

于 2009-05-07T16:44:40.350 に答える