視圖和演示者之間的MVP和打包周期

Question

我剛參加了一個使用GWT和MVP設計的項目。 他們使用以下結構：

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

在代碼中，Presenter知道其視圖，但該視圖也知道其Presenter，因此我在presenter.impl和view.impl之間的包中找到了循環

再三考慮，我問自己為什么impl鏈接自己而不是僅引用接口，從而避免了循環。

但是我也盡管“為什么視圖應該認識它的演示者？” 並查看一些談論MVP的站點，不清楚視圖和演示者是否應該彼此了解。

什么是最好的？

• 請他們使用接口消除循環？
• 要求從視圖中刪除presenter ，讓演示者直接處理用戶交互？
• 不執行任何操作，通常在MVP中的這些程序包之間循環

謝謝 ！

Answer 1

實際上，雖然主持人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);
    }
}

實際上，我通常將presenter接口聲明為嵌套在view接口中：

interface FooView extends IsWidget {

    interface Presenter {
       // ...
    }

    void setPresenter(Presenter presenter);

    // ...
}

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

Wrt表示知道impls，最重要的是演示者impl不引用視圖impl，因為（通常）它將防止在沒有GWTTestCase情況下對它進行單元測試（模擬視圖）。 反之則不成問題，但是與impl相比，您實際上並不需要presenter接口，對嗎？

[1]從技術上講，它可能是視圖隱含的，但通常是相反的，因此視圖可以超過演示者的壽命（演示者通常是輕量級的，與視圖相反，由於DOM操作，視圖的創建時間不可忽略）

Answer 2

使用MVP，演示者和視圖需要了解對應的接口 ：

• 演示者通常需要更新視圖
• 當事件（例如ValueChangeEvents）發生時，視圖將調用presenter方法。

請他們使用接口消除循環？

是。

要求從視圖中刪除演示者，讓演示者直接處理用戶交互？

不，那不是MVP。

不執行任何操作，通常在MVP中的這些程序包之間循環

那一定是剩下的周期是實例化循環：你不能兼得演示作為視圖的構造PARAM 和視圖作為主持人的構造PARAM。 這在基於構造函數的依賴注入中尤其明顯，並且在Java中理論上是不可避免的。 但是您可以選擇使用設置器（至少在一側），或使用帶有構造函數注入的工廠/ 提供程序 。