Роль EventBus в GWT - PullRequest
Новая
       25

Роль EventBus в GWT

9 голосов
/ 30 ноября 2011

Я читал об этой классной обработке событий в GWT с использованием EventBus, и пока мне это очень нравится.Но я не совсем понимаю, когда я должен его использовать.Все время?Могу ли я злоупотреблять этим?Должен ли я использовать его для всего, что связано с событием?(Как обмен данными между слоем представления и презентатора в MVP? Или я могу использовать его с событием onMouseMove? Насколько он тяжел?)

Итак, один вопрос: Какова роль EventBus в GWT?

Ответы [ 3 ]

5 голосов
/ 30 ноября 2011

Вы, вероятно, видели эту презентацию Google I / O: Архитектура Google Web Toolkit: лучшие практики для разработки вашего приложения GWT .

В нем рассматриваются аккуратные методы, позволяющие сделать работу с большими проектами GWT более управляемой, например использование шаблона команд для вызовов RPC, шаблона MVP, внедрения зависимостей и разъединение компонентов с использованием шаблона EventBus. Теперь есть несколько платформ GWT, которые реализуют эти шаблоны ( gwt-dispatch для шаблона команд, gwt-Presenter и gwt-platform для MVP, GIN & Guice для DI), но что мне нравится в концепции EventBus, так это то, что она является частью базовой инфраструктуры GWT (HandlerManager), поэтому мне не нужно добавлять дополнительные зависимости для небольших проектов GWT.

Я думаю, что концепция EventBus связана с шаблоном проектирования Observer в том смысле, что вы отделяете компоненты View, отвечающие за получение пользовательского ввода от компонентов Presenter, которые должны быть уведомлены об этих действиях. Дело в том, что вашему ListBox не нужно знать обо всех компонентах, которые заинтересованы в изменении его состояния, он просто запускает событие в EventBus, и заинтересованные компоненты получают это событие и действуют так, как они хотят.

Я не думаю, что вам всегда нужно делать что-то через экземпляр HandlerManager. Предположим, у вас есть пользовательский виджет DateRangePicker, который позволяет пользователям выбирать настраиваемые диапазоны дат. Всякий раз, когда выбирается диапазон дат, виджет может делать что-то подобное в своем методе onSomethingChanged(): 

NativeEvent event = Document.get().createChangeEvent();
DomEvent.fireNativeEvent(event, this);

Тогда компоненты, заинтересованные в изменении выбора диапазона дат, могут просто зарегистрировать обратные вызовы в виде хандера для экземпляров виджета DateRangePicker. 

dateRangePicker.addDomHandler(new ChangeHandler(){
    @Override
    public void onChange(ChangeEvent event) {
        refresh();
    }
}, ChangeEvent.getType());

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

Плохой дизайн - вызывать все методы refresh() всех заинтересованных компонентов в методе onRomegeChange () DateRangePicker вместо вызова события. (Или еще хуже: вызов всех refresh () - в методах onSomethingChange () подкомпонента объекта DateRangePicker.)

3 голосов
/ 01 декабря 2011

Я думаю, что использование глобального EventBus для внутренней связи между частями MVP одного виджета несколько злоупотребляет. Это сделало бы ваш виджет зависимым от события. (Если бы шлюз событий отсутствовал в ядре GWT, это было бы более неприемлемо.) Я считаю, что шина событий является средством связи между различными виджетами разных частей приложения.

2 голосов
/ 30 ноября 2011

Было бы довольно бесполезно использовать это между представлением и презентатором, вместо того, чтобы просто вызывать презентатора для непосредственного вызова метода представления.

Я считаю, что EventBus хорош, когда компоненты не ссылаются друг на друга, например, презентаторы двух разных экранов.

...