GWT MVP UiBinder - 将参数传递给演示者

Question

我已经开始了一个 GWT 项目，我决定尝试一下 UiBinder。我很难在 UiBinder 之上建立 MVP 模式。

当我使用 GWT-pure-java 时：我会使用 Gin 向我的演示者注入相应的视图。这非常简单，如果我想将 id 传递给演示者，那么我只需将 id 传递给演示者的构造函数即可。

UiBinder 就不那么简单了。我几乎可以肯定我错过了一些东西，因为很多人都声称 UiBinder 和 MVP 是天作之合......所以我希望在这个问题上得到一些可靠的答复;-)

我是什么我们在几个简单的 GWT-UiBinder 示例中看到的是，视图是由绑定器创建的，然后：

1. 视图在其构造函数中或通过 @UIFactory 方法构造呈现器。
2. 相应的presenter被传递给view（通过setter，不用说是在view构造之后）。

使用第一种方法，如果在视图中构造演示者，如何将 id 传递给演示者？你会做view.getPresenter().setId(42);，然后演示者会去服务器获取一些信息并要求视图显示它......闻起来很糟糕。

使用第二种方法，最终会得到一个不直观的对象图，其中不清楚谁是消费者，谁是生产者。另外，在视图需要来自演示者的信息的情况下（几乎所有用例都需要这个），人们会做什么：

//some code would create the presenter pass it the id and then call view.setPresenter
class MyView {
    void setPresenter(MyPresenter p) {
    this.presenter = p;
    //OK now that i have my presenter how do I ask it to fetch data from the server.
    //do i turn around and do: presenter.setView(this); and then the presenter takes 
    //over and uses the view to display the data?
     }
 }

这同样很臭……抱歉，帖子很长，提前感谢……

Answer 1

你是对的，让视图引用其演示者，并让演示者引用视图确实看起来有点不干净。

在我看来，以及 MVP 上的 google 开发页面如何概述 MVP 有两种风格：

1. 拥有一个不知道其演示者的视图，并用演示者“包装”它。视图为演示者提供了足够的 API 来获取/设置它关心的所有数据。此外，演示者必须了解视图可以生成的所有事件类型，以便响应用户交互。这是MPV 第 1 部分 的方法。
2. 演示者再次了解视图，但这次仅具有获取/设置数据的能力。演示者不关心视图中的 UI 事件。相反，演示器为视图提供了一个 API，以便在事件以演示器中的“onSomethingHappened()”方法的形式发生时调用/通知它。这使我们能够捕获演示者本身的所有行为/逻辑，并在视图中发生某些情况时根据需要调用它。然后，视图可以以任何合适的方式在非常低的级别处理事件 - 无论是使用 GWT 事件/小部件还是使用元素/HTML 的原始 DOM 事件（UiBinder/GWT 性能最佳实践）。这是MVP 第 2 部分 的方法。

我更喜欢选项 2，因为它允许演示者完全专注于必要的行为。视图可以根据需要处理小部件/html/事件处理，并将其简化为对演示者的“onSomething()”调用。这些小部件/事件实现可能是简单的或复杂的和优化的事件。演示者不会受到细节的影响（也不会受到污染），因为它只是收到通知。我觉得这个选项可以更清晰地分离表现和行为。请注意，它也是 观察者模式 的 1 对 1 实现，因此 View 和 View 之间的互连主持人是必要的。

至于创作，我觉得演示者是更强的实体，尽管它扮演的是观察者的角色。我将创建必要的演示者，然后将关注的视图传递给它。然后演示者可以控制视图，并向视图传递自引用。

至于你的生产者/消费者的类比，我认为演示者就是消费者。视图生成 UI 事件（用户交互），演示者通过提供必要的行为进行响应。这应该是视图和演示者之间的唯一联系点 - 视图调用“onSomethingHappened()”等方法，然后演示者完成工作。视图永远不会告诉演示者“fetchData()”或类似的内容。

我自己最近才开始使用UiBinder + MVP，所以这只是我的想法。我希望它有帮助！

Answer 2

自从我开始这个帖子并阅读回复以来已经过去了几天。我已经决定了我的方法。我以为我只是在这里提到它。

再次感谢您的深思熟虑的回复……他们很有帮助。

由于 filip-fku 指出演示者是主要实体，因此我决定在我的 mvp 对象的生命周期管理期间继续威胁他们。换句话说，视图不会实例化演示者。演示者由其他演示者实例化（在某些时候我将委托给 Gin）。

演示者的构建器可以访问其相应的视图，并将视图注入演示者（通过构造函数）。

视图本身要么由构建器实例化，要么由 UiBinder 实例化为更大视图的一部分。在后一种情况下，UiBinder 实例化视图，父视图有一个 getter。下面是这种情况的一个示例：

/*pojo for the parent ui-binder*/
public class Form implements FormPresenter.View {
@UiField PromptView namePrompt;
@override
PromptPresenter.View getNamePromptDisplay() {
    return namePrompt;  //introduced into this pojo via @UiField
}
//bunch of view code
}//end of the class

然后在 FormPresenter 中我这样做：

private void buildNamePrompt() {
  new PromptPresenter(display.getNamePromptDisplay(), etc....);
}

我基本上保持了与纯 java 方法类似的 mvp 生命周期。一旦我从中获得一些里程，我将用 Gin 重构它。

再次感谢。
PS，如果您还没有看过上面提到的 I/O 演示，那么值得一看。