GWT MVP с местами и деятельностью - где модель? - PullRequest
Новая
       35

GWT MVP с местами и деятельностью - где модель?

14 голосов
/ 01 апреля 2011

Я пытаюсь ознакомиться с шаблоном проектирования «Места и занятия» для разработки GWT, и до сих пор думаю, что у него большой потенциал. Мне особенно нравится то, как, когда вы начинаете думать о своем приложении с точки зрения «Мест», история браузера практически просто ложится вам на колени практически без лишних усилий.

Тем не менее, меня беспокоит только одно: все статьи и примеры кода, которые я видел до сих пор, затуманивают один (на мой взгляд, основной) аспект: часть «M» в «MVP», т.е. Модель!

Насколько я понимаю, в обычной архитектуре MVP Presenter хранит ссылку на модель и отвечает за ее обновление в соответствии с событиями пользовательского интерфейса или, соответственно, обновление пользовательского интерфейса в соответствии с изменениями модели.

Теперь, во всех статьях / примерах для "P & A", кажется, что действия занимают место докладчика, но в отличие от "обычных" докладчиков, они отбрасываются и (заново) создаются всякий раз, когда появляется новое место, поэтому они не могут хранить состояние клиента, иначе оно будет потеряно каждый раз. Создание действий обходится дешево, поэтому это не составляет особого труда, но я бы не хотел создавать модель сложного приложения снова и снова.

Все примеры довольно просты и не имеют большой части состояния, и поэтому просто игнорируют аспект модели, но где в реальном сложном приложении будет храниться его состояние?

Ответы [ 2 ]

10 голосов
/ 01 апреля 2011

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

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 в «классическом» смысле имеет гораздо более длительный срок службы, чтобы поддерживать связь между моделью и пользовательским интерфейсом.Поэтому я реализовал отдельный Presenter с использованием стандартного шаблона проектирования MVP, и все, что делает Activity, выглядит примерно так: 

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

9 голосов
/ 01 апреля 2011

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

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

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

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

...