最近頻繁に遭遇する問題の1つは、発表者のクラスが大きくなりすぎるという問題です。通常、私はビートをスキップせずに通常の大きなクラスを切り刻むことができます。しかし、プレゼンターは時にはコードをもっと難しくすることなく、少し落ち着かせるのが難しいです。大きすぎるMVPインターフェイスパターンのプレゼンターを分割するための良い方法はありますか？
特に、ページがCRUD指向のコントロールでいっぱいになるとき。時にはコントロールを分割することもありますが、他のコントロールの影響を受ける場合、調整ロジックは複雑です。時々私はリストまたはグリッドデータの検索を分割することがありますが、時には同様の落とし穴があります。
あなたがプレゼンターからリファクタリングする技術や経験則や共通の領域はありますか？
私は通常2つのアプローチを使用します。
更新
ビューを分割、Iは、典型的には、インターフェイスを分割し、私の形態は、複数のインタフェースを実装有することによって開始します。
public class ComplexForm: Form, ISubView, IOtherSubView
{
...
}
次に、私が作成した多くのビューにプレゼンターを分割しました。
public class SubViewPresenter
{
private ISubView subView;
...
}
public class OtherSubViewPresenter
{
private IOtherSubView otherSubView;
...
}
さらに進んで、ISubViewおよびIOtherSubViewの実装をユーザーコントロールに移動するか、そのまま使用することができます。 パッシブビューパターンを使用している場合、フォームはUIロジックのみを処理するため、これは子供の遊びです。プレゼンターを分割すると、プレゼンター同士の直接コミュニケーションを避けようとしています。通信が必要な場合は、間接的にドメインオブジェクトを使用して通信を試みます。
DALにデータを渡すこと以外のアクティビティを実行するコードを抽出するか、ビューにプッシュするようにしてください。たとえば、電子メールの更新やビジネスロジックの実行が必要な場合は、それらを別々のクラスに抽出してください。私はしばしば同じ問題を扱い、可能な限り多くのロジックを個々のドメイン/エンティティクラスに移動し、そこで検証を実行しようとしていました。
希望すると便利です。
ニースの回答、ありがとう –
ニースの答え。私はあなたが次にクロスビュー、それが伴うかもしれないクロスプレゼンターのコミュニケーションをどのように処理するのか興味があります。あなたの意見と発表者はお互いに話しますか？ –
この技法のデモンストレーションの例を追加しました。 –
こんにちは、ありがとう、それは素晴らしい答えでした –