视图和演示者之间的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中理论上是不可避免的。 但是您可以选择使用设置器（至少在一侧），或使用带有构造函数注入的工厂/ 提供程序 。