GWT MVP with Places &活动 - 模型在哪里? [英] GWT MVP with Places & Activities - Where's the Model?

问题描述

我正在努力熟悉 GWT 开发的场所和活动"设计模式，到目前为止，我认为它具有很大的潜力.我特别喜欢这样的方式:一旦您开始从位置"的角度考虑您的应用程序，浏览器历史记录几乎就在您的腿上，几乎不需要额外的努力.

I'm trying to familiarize myself with the "Places & Activities" design pattern for GWT development, and so far I think it has a lot of potential. I especially like the way how once you start thinking about your application in terms of "Places", browser history virtually just lands in your lap with almost no extra effort.

然而，有一件事让我感到困扰:到目前为止，我所看到的所有文章和代码示例都掩盖了一个(就我而言，主要)方面:MVP"的M"部分，即模型！

However, one thing just bothers me: All the articles and code examples I've seen so far gloss over one (as far as I am concerned, major) aspect: the 'M' part of the 'MVP', i.e. the Model!

在正常的MVP架构中，据我所知，Presenter持有对Model的引用，负责根据UI事件更新它，或者分别根据Model的变化更新UI.

In normal MVP architecture, as far as I understand it, the Presenter holds a reference to the Model, and is responsible for updating it according to UI events or, respectivly, updating the UI according to Model changes.

现在，在P&A"的所有文章/示例中，活动似乎正在取代演示者，但与正常"演示者不同的是，只要有新地点到达，它们就会被丢弃并(重新)创建，所以他们不能存储客户端状态，否则每次都会丢失.Activity 的创建成本很低，所以不会很麻烦，但我不想一遍又一遍地创建复杂应用程序的模型.

Now, in all the articles/samples for "P&A" the Activities seem to be taking the place of the Presenter, but unlike 'normal' Presenters, they get discarded and (re-)created whenever a new Place arrives, so they can't be the ones to store the client state, or it would be lost every time. Activities are cheap to create, so it's not much of a hassle, but I wouldn't want to create the model of a complex application over and over again.

所有示例都相当简单，没有太多状态，因此忽略了模型方面，但实际复杂的应用程序将在哪里存储其状态?

All the samples are fairly simple and don't have much of a state and therefore just ignore the Model aspect, but where would an actual, complex application store its state?

推荐答案

我想我找到了自己的答案.主要问题似乎是所有简单的代码示例都使 Activities 成为 Presenter，如下所示:

I think I found my own answer. The main problem seems to be that all of the simple code examples make the Activities be the Presenters, as in:

public class NavigationActivity extends AbstractActivity implements NavigationView.Presenter {
    private final ClientFactory clientFactory;
    private final NavigationPlace place;

    public NavigationActivity(ClientFactory clientFactory, NavigationPlace place) {
        this.clientFactory = clientFactory;
        this.place = place;
    }

    @Override
    public void start(AcceptsOneWidget panel, EventBus eventBus) {
        NavigationView navView = clientFactory.getNavigationView();
        navView.setSearchTerm(place.getSearchTerm());
        navView.setPresenter(this);
        panel.setWidget(navView);
    }

    @Override
    public void goTo(Place place) {
        clientFactory.getPlaceController().goTo(place);
    }
}

现在活动的生命周期相当短，而经典"意义上的典型 Presenter 具有更长的生命周期，以保持模型和 UI 之间的绑定.所以我所做的是使用标准的 MVP 设计模式实现一个单独的 Presenter，而 Activity 所做的就是这样:

Now Activities are fairly short-lived, whereas a typical Presenter in the 'classical' sense has a much longer lifespan in order to maintain the binding between the model and the UI. So what I did was to implement a separate Presenter using the standard MVP design pattern, and all the Activity does is something like this:

public class NavigationActivity extends AbstractActivity {
    private final ClientFactory clientFactory;
    private final NavigationPlace place;

    public NavigationActivity(ClientFactory clientFactory, NavigationPlace place) {
        this.clientFactory = clientFactory;
        this.place = place;
    }

    @Override
    public void start(AcceptsOneWidget panel, EventBus eventBus) {
        NavigationPresenter presenter = clientFactory.getNavigationPresenter();
        presenter.setSearchTerm(place.getSearchTerm());
        presenter.go(panel);
    }
}

因此，不是 Activity 获取 View 并在其上充当演示者，而是获取 实际 演示者，只是通知它引起的客户端状态更改通过 Place，并告诉它在哪里显示它的信息(即视图).然后 Presenter 可以自由地以任何它喜欢的方式管理视图和模型 - 这种方式比我发现的代码示例要好得多(至少对于我正在处理的应用程序的想法)远.

So, instead of the Activity fetching the View, and acting like a Presenter on it, it fetches the actual Presenter, just informs it of the client state change induced by the Place, and tells it where to display its information (i.e. the view). And the Presenter is then free to manage the view and the model any way it likes - this way works a lot better (at least with what I have in mind for the application I'm working on) than the code examples I have found so far.

这篇关于GWT MVP with Places &活动 - 模型在哪里?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！