2

私はちょうど彼らがGWTとMVPデザインを使用するプロジェクトに参加しました。次の構造を使用します。

client.mvp.presenter (contains interfaces)
client.mvp.presenter.impl
client.mvp.view (contains interfaces)
client.mvp.view.impl

コードでは、プレゼンターはそのビューを認識していますが、ビューはそのプレゼンターも認識しているため、パッケージ内にpresenter.implとview.implの間のサイクルが見つかりました。

そのことをもう一度考えて、インターフェイスだけを参照するのではなく、なぜ自分自身をimplリンクしてサイクルを回避するのかを自問しました。

しかし、私はまた、「なぜビューはそのプレゼンターを知っている必要があるのですか？」そして、MVPについて話しているサイトを見ると、ビューとプレゼンターがお互いを知っているべきかどうかはそれほど明確ではありません。

何が一番いいでしょうか？

  • インターフェースを使用してサイクルを削除するように依頼しますか？
  • ビューから削除presenterして、プレゼンターにユーザーの操作を直接処理させるように依頼しますか？
  • 何もしないでください。通常、MVPでこれらのパッケージ間を循環します。

ありがとう ！

4

2 に答える 2

3

実際、プレゼンターimpl [1]はビュー（インターフェース）を必要としますが、プレゼンターインターフェースは一般的に必要ありません。

典型的なパターンは次のとおりです。

interface FooPresenter {
   // methods called by the view (generally in response to user interaction)
   void doSomething(String foo);
}

interface FooView {
   /** Tells the view which presenter instance to call back. */
   void setPresenter(FooPresenter presenter);

   // methods called by the presenter to control the view
   void showSomething(String foo);
}

class FooPresenterImpl implements FooPresenter {
    private final FooView view;

    FooPresenterImpl(FooView view, /* other dependencies here */) {
       this.view = view;
    }

    // could also be the start() method of com.google.gwt.activity.shared.Activity
    public void init() {
       view.setPresenter(this);
    }

    // optional; could be called from onStop() and onCancel() if using Activity
    public void dispose() {
       view.setPresenter(null);
    }
}

実際、私は通常、ビューインターフェイス内にネストされたプレゼンターインターフェイスを宣言します。

interface FooView extends IsWidget {

    interface Presenter {
       // ...
    }

    void setPresenter(Presenter presenter);

    // ...
}

class FooPresenter extends AbstractActivity implements FooView.Presenter {
   // ...
}

Wrt implsはimplsを知っていますが、最も重要なのは、プレゼンターimplがビューimplを参照しないことです。これは、（一般に）GWTTestCase（ビューをモックする）なしでユニットテストを実行できないためです。逆はそれほど問題ではありませんが、プレゼンターインターフェイスとimplは実際には必要ありません。

[1]技術的にはビューの実装である可能性がありますが、通常は逆であるため、ビューはプレゼンターよりも長持ちします（プレゼンターは、DOM操作のために作成時間が無視できないビューとは対照的に、一般的に軽量です）

于 2012-10-03T10:39:28.243 に答える
1

MVPの場合、プレゼンターとビューは対応するインターフェイスを知る必要があります。

  • プレゼンターは通常、ビューを更新する必要があります
  • イベント（ValueChangeEventsなど）が発生すると、ビューはプレゼンターメソッドを呼び出します。

インターフェースを使用してサイクルを削除するように依頼しますか？

はい。

プレゼンターをビューから削除し、プレゼンターにユーザーの操作を直接処理させるように依頼しますか？

いいえ、それはMVPではありません。

何もしないでください。通常、MVPでこれらのパッケージ間を循環します。

必然的に残るサイクルは、インスタンス化のサイクルです。ビューのコンストラクターパラメーターとしてのプレゼンターとプレゼンターのコンストラクターパラメーターとしてのビューの両方を持つことはできません。これは、コンストラクターベースの依存性注入で特に明白になり、Javaでは理論的に避けられません。ただし、セッター（少なくとも片側）を使用するか、コンストラクターインジェクションでファクトリ/プロバイダーを使用するかを選択できます。

于 2012-10-03T10:18:45.033 に答える