GWT MVP с местами и мероприятиями - Где модель?

Ответ 1

Я думаю, что нашел свой собственный ответ. Основная проблема заключается в том, что все простые примеры кода делают действия "Ведущие", как в:

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);
    }
}

Теперь действия довольно короткоживущие, тогда как типичный Презентатор в "классическом" смысле имеет гораздо более продолжительный срок службы, чтобы поддерживать привязку между моделью и пользовательским интерфейсом. Так что я сделал, чтобы реализовать отдельный презентатор, используя стандартный шаблон дизайна MVP, и все действия выполняются примерно так:

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, получая представление и действуя как презентатор на нем, он извлекает фактический Presenter, просто информирует об изменении состояния клиента, вызванном Place, и сообщает ему, где отображать его информацию (т.е. вид). И тогда Presenter может свободно управлять представлением и моделью любым способом, который ему нравится - этот способ работает намного лучше (по крайней мере, с тем, что я имею в виду для приложения, над которым я работаю), чем примеры кода, которые я нашел так далеко.

Ответ 2

Вы правы, почти всегда ведущий - единственный парень, который держит модель и управляет ее жизнью. Модель из предыдущих версий GWT просто была DTO (и продолжает быть) POJO, которые создаются десериализатором GWT, когда методы RPC возвращаются или создаются Ведущими и заполняются данными пользовательского интерфейса UIHandlers, и отправляется на сервер.

Я приложил усилия, чтобы сохранить время жизни моделей, инкапсулированное в течение жизненного цикла Activities, и избегать хранения состояния вне действий. (Тем не менее, у меня есть одноэлементное глобальное состояние, которое поддерживается для использования в любом месте приложения.) Я думаю, что это то, что предполагают инженеры GWT MVP, - это имеет смысл, если, скажем, пользователь перешел от Place, поскольку модели, связанные с этим местом, также должны быть расположены (и собраны). Создавайте модели, заполняйте их внутри своих действий и делайте служебные вызовы для обновления сервера перед тем, как перейти (или вызван каким-то контролем на странице), и позволить им идти в ногу с деятельностью - это то, что я делал до настоящего времени.

Более крупный проект, в котором я участвовал, столкнулся с несколькими проблемами с памятью в памяти браузера, и все они были связаны с объектами, которые связаны с другим (не просмотренным в настоящее время) местом, находящимся в памяти. Трудно было отслеживать и удалять ссылки на эти объекты, а так как пользователь перешел от экрана - "почему мои старые экранные объекты все еще в памяти?" часто возникал вопрос, а затем исправлялся. Вот почему, заранее, я решил сохранить время жизни модели, инкапсулированное в течение жизненного цикла Activities в моем текущем проекте для домашних животных.

Если у вас есть модели, которые охватывают (которые заполняются/получают доступ) несколькими действиями (как в случае, если у вас есть боковые панели и виджеты мастера/контейнера), некоторые изменения дизайна могут быть в порядке, если у вас есть примеры, которые я буду попробуйте и помогите.